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

proposal: distinguish explicitly vs implicitly added registries #3880

Open
StefanKarpinski opened this issue Apr 23, 2024 · 1 comment
Open

Comments

@StefanKarpinski
Copy link
Sponsor Member

Right now we don't distinguish between whether a registry was added explicitly by the user via registry add X or it was automatically/implicitly added because the user didn't have any registries added and the package server offers it. This leads to various confusions:

  • If the user happens to add a registry first, then they won't get any registries from the package server.
  • If what registries the package server offers changes, then the old ones linger and the new ones may not be picked up.

Instead, I would propose that we have two kinds of registries:

  1. Explicitly added registries, which are always considered until the user explicitly removes them.
  2. Implicitly added registries, which are only considered if the current package server offers them.

We could consider gc'ing implicitly added registries if they haven't been offered in a long time, so we may want to keep track of the last time we talked to a package server that offered an implicitly added registry. This would alleviate the above issues:

  • If a user adds a registry first, it doesn't matter—they'll use that as well as whatever registries their package server offers and the order of events doesn't matter.
  • If the user switches package servers or what registries a package server offers changes, we'll only consider packages included in the explicit registries as well as the ones included in the registries offered by the current package server.

Thoughts on this approach. Spurred by having long wanted this and conversation with @KristofferC and @Keno.

@johnnychen94
Copy link
Sponsor Member

FYI, #3503 is a concrete example for this.

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

2 participants