Can Versions.toml point to git branch instead of fixed git commit?

#1

for creating one’s own registry one has to specify Versions.toml for each package

currently it seems like you have to link versions to concrete git commits via hash, however for development it would be very helpful to link to branches instead.

Is this already possible?
can this be enabled?

Registry: support resolving dependencies also when Versions.toml file is empty by using master
#2

If you dev a package then it only needs the path, not anything else.

#3

true, however I for developing in a shared environment (cross OS, cross Machine, cross user)
a registry is useful for sharing

in the registry I need to specify versions for things to work at all, even if I don’t have any stable version yet.

It would be super natural to instead point the registry directly to a develop branch (or master) so that people can try out my develop version by just taking my registry and everything works as normal.

#4

Thats why you can add by a branch, then $ pkg update will automatically follow that branch. The purpose of the registry is to hold information about releases, not floating targets like a branch.

#5

Might be cool to allow instantiating a manifest with dev’d packages and let it automatically check them out on the indicated branch. Agree that putting branches in the registry is not the way to go.

#6

Yea, that is basically https://github.com/JuliaLang/Pkg.jl/pull/1088.

Another thing that I have used a bit is to include the package in a registry, without any versions. That at least allows for e.g. $ pkg add UnregisteredPackage#branch etc, which is pretty handy.

2 Likes
#7

Okay, now that https://github.com/JuliaLang/Pkg.jl/issues/1005 is going to be solved things look different.

Still there is the following problem:

  • when relying on a manifest file to share the dependencies, it should stay somehow fixed for every package
  • still I want to develop certain packages, henc devthem, which will change the manifest of my current project

What I imagine is solving this is

  • on the single packages I can add git:mydepencency#master
  • when wanting to dev git:mydepency I rather use another project like ‘main’ or the default julia1.3 project or similar and dev git:mydependency there
  • is guaranteed that when running things from ‘main’ that also the subpackages refer to the package in development (which may not yet have been pushed to master)?
  • the only way to get that manifest on different machines is to version control it, however this conflicts with the fact that in development you rather often may want to dev parts of your project, hence changing the manifest file
#8

I tried having a registry without any versions, however this failed immediately for adding packages which have other private packages in their dependencies (something like “no suitable version could be found for dependency …” was raised, which at least makes sense as no version is given)

EDIT: this brought me to a different approach to be able to better use registries also for initial development phase. Please see Registry: support resolving dependencies also when Versions.toml file is empty by using master