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?
If you dev a package then it only needs the path, not anything else.
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.
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.
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.
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.
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
- 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
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