# UUID for forked packages? Depending on a forked package?

**URL:** <https://discourse.julialang.org/t/uuid-for-forked-packages-depending-on-a-forked-package/56151>\
**Category:** Package Management\
**Created:** [February 27, 2021, 6:56pm UTC](https://discourse.julialang.org/t/uuid-for-forked-packages-depending-on-a-forked-package/56151 "2021-02-27T18:56:26Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![evanfields](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/evanfields/32/1744_2.png) [@evanfields](https://discourse.julialang.org/u/evanfields)\
**Post date:** [February 27, 2021, 6:56pm UTC](https://discourse.julialang.org/t/uuid-for-forked-packages-depending-on-a-forked-package/56151/1 "2021-02-27T18:56:26Z")

</div>

1. I’ve forked the original [Hexagons.jl](https://github.com/GiovineItalia/Hexagons.jl) to create [my own version](https://github.com/evanfields/Hexagons.jl). 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.jl` in 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?

2. HexGeoGrids.jl is a personal project of mine ([github source](https://github.com/evanfields/HexGeoGrids.jl), [explanatory blog post](https://evanfields.github.io/No-Perfect-Geo-Grid/)) which depends on my Hexagons.jl fork. This works fine locally, where the `Manifest.toml` is present:

```julia
(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](https://julialang.github.io/Pkg.jl/v1/compatibility/) only describe semver based compatibility. And indeed, while my local `Manifest.toml` points towards the right repo:

```julia
[[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`](https://github.com/evanfields/HexGeoGrids.jl/blob/main/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?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 28, 2021, 10:14am UTC](https://discourse.julialang.org/t/uuid-for-forked-packages-depending-on-a-forked-package/56151/2 "2021-02-28T10:14:28Z")

</div>

> [@evanfields](#):
>
> Should the forked package have its own UUID?

AFAIK the customs for forking packages have not really evolved yet, since it is uncommon (personally, I think it should be _more_ common and the right way to deal with dead projects). Technically, you can recycle the name and change the UUID, but I would recommend choosing a different name for your forked package for now.

> [@evanfields](#):
>
> package repos should _not_ contain a `Manifest.toml` , right?

Generally, yes.

> [@evanfields](#):
>
> How can I represent in the `Project.toml` that the project depends on a fork of Hexagons.jl, i.e. a specific github repo?

You can’t, that’s not how it works.