-
I’ve forked the original Hexagons.jl to create my own version. Should the forked package have its own UUID? If I intend for the fork to diverge and become its own independent package, then “yes” would seem reasonable. But in this case, it’s unclear whether I’m hoping for a) my changes to get pulled into the original; b) my package to become the
Hexagons.jlin the general registry [upstream does not seem maintained]; c) the packages to diverge and remain separate–in which case do I need to find a new name? Given that, what should I do about UUID and name? -
HexGeoGrids.jl is a personal project of mine (github source, explanatory blog post) which depends on my Hexagons.jl fork. This works fine locally, where the
Manifest.tomlis present:
(HexGeoGrids) pkg> st Hexagons
Project HexGeoGrids v0.1.0
Status `C:\Users\ejfie\.julia\dev\HexGeoGrids\Project.toml`
[a1b4810d] Hexagons v0.2.0+ `https://github.com/evanfields/Hexagons.jl#master`
But as I understand it, package repos should not contain a Manifest.toml, right? The Project.toml describes what the package is an what its deps are; the Manifest.toml is the “output” of the resolver? How can I represent in the Project.toml that the project depends on a fork of Hexagons.jl, i.e. a specific github repo? This would seem to be a job for the [compat] section, but the Pkg docs only describe semver based compatibility. And indeed, while my local Manifest.toml points towards the right repo:
[[Hexagons]]
git-tree-sha1 = "fa592f180b6405907633d82043d86ca324c0f772"
repo-rev = "master"
repo-url = "https://github.com/evanfields/Hexagons.jl"
uuid = "a1b4810d-1bce-5fbd-ac56-80944d57a21f"
version = "0.2.0+"
The Project.toml does not. So how can I make sure that, in the cosmically unlikely event someone wants to try out my personal project, they get the right version of Hexagons.jl?