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

this is a follow up idea on Can Versions.toml point to git branch instead of fixed git commit?

concretely does the current registry already work with an empty Versions.toml file in the restricted situation of just adding one package which does not have any other dependency without a Versions.toml.

Lets say I have package a private A depending on private package B which has no further dependency.
Both i registered in my private registry, both having only an empty Version.toml file. Having the registry linnked to my current julia…

… I cannot do

] add A

because it searches for a version for B but cannot find any and fails

… however I can in fact do

] add B

which will install it from master from the respective git respository link defined in the Registry entry.
(after having B installed, I can also add A of course)

hence my proposal:

make it possible to resolve dependencies within a registry also when no version is defined in Versions.toml, defaulting to master branch of the defined git repository

  • this would just mimick functionality which is already there as elaborated above
  • it is obvious and explicit for everyone that indeed no version is ready to be installed, but that this is development
  • the fallback to master of the linked repository is already the default and perfectly fits the usecase for (initial) development with no stable versions yet

@fredrikekre may I ask you for your opinion about this?

I don’t think you can, since there are no versions of B either, e.g.:

$ pkg registry add https://github.com/fredrikekre/Staging
   Cloning registry from "https://github.com/fredrikekre/Staging"
     Added registry `Staging` to `~/.julia/registries/Staging`

$ pkg add JuAFEM
 Resolving package versions...
ResolverError: Unsatisfiable requirements detected for package JuAFEM [30d91d44]:
 JuAFEM [30d91d44] log:
 ├─JuAFEM [30d91d44] has no known versions!
 └─restricted to versions * by an explicit requirement — no versions left

However, you should be able to do

$ pkg add A#master B#master
2 Likes

thanks a lot. I was really sure this was because of a dependency, but then I probably haven’t looked detailed enough. (the dependency problem was the major problem I had before locally, because of https://github.com/JuliaLang/Pkg.jl/pull/1088. This topic here occured when wanting to jump between machines. Apparently this got me confused). I hope I find time soon to check this again on my system.

EDIT: I found the difference. I directly installed the package using ] dev instead of ] add. I tried it with your Staging area, and could successfully run ] dev JuAFEM after adding the registry.


Still I think it is very valuable to have this fallback feature in the Registry. Reasons:

  • it simplifies the initial phase when developing new packages a lot

  • it does not bind versions to branches (as disliked in another discourse discussion), but only has a fallback branch when no version is given

  • with it the registry is the one central place where you can register all your packages in development

    For comparison: The pull request https://github.com/JuliaLang/Pkg.jl/pull/1088 only works with Manifest-files within each of the packages to be installed. Hence you have to curate the manifest files for all packages independently. Which is especially cumbersome because this stage development you are constantly working with ] develop ... installations, which will alter your manifest file.

  • when using a registry today for this purpose, you artificially have to bind a git commit tree-hash to a thought-up version number, while there is in fact no stable version yet to use at this stage of development. This would no longer be needed, as the Versions.toml could stay empty

Anyone else having doubts?

I think this is a very appropriate addition towards Julia Registries
In case no further complains arise, I will push it as feature-request on Julia github

EDIT: I just opened a feature request https://github.com/JuliaLang/julia/issues/34515