Open KristofferC opened 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.
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"
Until we have a satisfactory solution to #2393 (dependency confusion), I'd be wary of adding registries without confirmation.
From https://github.com/JuliaLang/Pkg.jl/pull/3783#issuecomment-1974794079
[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:
or maybe this should be a dict and be
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