Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
KristofferC opened this issue Mar 14, 2024 · 3 comments
Open

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

KristofferC opened this issue Mar 14, 2024 · 3 comments

Comments

@KristofferC
Copy link
Sponsor Member

From #3783 (comment)

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
Copy link
Contributor

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
Copy link
Sponsor Member

vchuravy commented Mar 29, 2024

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants