JuliaLang / Pkg.jl

Pkg - Package manager for the Julia programming language
https://pkgdocs.julialang.org
Other
609 stars 251 forks source link

Specifying registries needed for a project in the Project file #3845

Open KristofferC opened 3 months ago

KristofferC commented 3 months ago

From https://github.com/JuliaLang/Pkg.jl/pull/3783#issuecomment-1974794079

Could it make sense to be able to specify a registry in the sources block? Maybe with a separate registries block to have the url. That way a Project/Manifest does not need to depend on the registries already being installed.

[sources] made it easier to resolve a manifest with unregistered dependencies without having to manually add these dependencies by URL. However, you still need to make sure that the registries are available. So the next step would be to store the set of registries needed in the project file as well so that they are automatically installed for you.

This issue is about how to specify that information in the project file.

The first question is if we need to store the UUID of the registry somewhere. It's kind of silly since there are so few registries. If we then only look at the registry name we could have:

[registries]
CustomRegistry = "https://my.custom.registry/CustomRegistry"
...

or maybe this should be a dict and be

[registries]
CustomRegistry = {url = "https://my.custom.registry/CustomRegistry"}
...

Should custom registries be auto-added to the project file once a package is added to the project that is not available in general?


cc @ericphanson, @Seelengrab

Seelengrab commented 3 months ago

I don't have much of an opinion on how exactly the data is stored, but IMO having the UUID doesn't really cost us all that much but is a gain UX wise. We should already check for uniqueness when doing ]registry add right?

Should custom registries be auto-added to the project file once a package is added to the project that is not available in general?

I think so, yeah. Without that information, the project is still not instantiable from just Project.toml alone. Making General less special in that regard seems fruitful to me, so that other installations can e.g. completely remove General and just have their (perhaps vetted) registry. In that sense, General should also be added to [registries] as soon as a package is added that's sourced from it.

vchuravy commented 3 months ago

Copying what I just posted in Slack here:

One thought with regards to [sources] I just came across a package that has dependencies that exist in a different registry. It would be nice if we had a section in the Project.toml that would prompt the user upon a Pkg.add(url) to add the corresponding registries. Maybe in [sources] we could even state the registry the package is coming from allowing for version resolution over just tracking a branch.

Should custom registries be auto-added to the project file once a package is added to the project that is not available in general?

Hm, my gut went with asking before adding the registry, but maybe auto-adding is fine.

The first question is if we need to store the UUID of the registry somewhere. It's kind of silly since there are so few registries. If we then only look at the registry name we could have:

We could make it follow the same semantics as a Pkg.

[registries]
CustomRegistry = UUID

[sources]
CustomRegistry = "https://my.custom.registry/CustomRegistry"
GunnarFarneback commented 3 months ago

Until we have a satisfactory solution to #2393 (dependency confusion), I'd be wary of adding registries without confirmation.