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

Advertisement of the registries that PkgServer knows about #26

Open
mbauman opened this issue Apr 20, 2020 · 10 comments
Open

Advertisement of the registries that PkgServer knows about #26

mbauman opened this issue Apr 20, 2020 · 10 comments

Comments

@mbauman
Copy link

mbauman commented Apr 20, 2020

Since a great use of a Package Server is to coordinate work across multiple registries — potentially a private registry in addition to the General one — it'd be helpful if the Package Server could advertise which registries are available. This could allow for two niceties on the client side:

  • Adding the private registry by name — like how ] registry add General is currently special-cased.

and/or

  • Automatically ensuring all advertised registries are added upon first connection
@StefanKarpinski
Copy link
Collaborator

I think we should actually do more than this: when you update and you're talking to a Pkg server, you should automatically install and update all the registries that it advertises. That way you set the Pkg server and you automatically know about all the right packages. Making people mess about with adding and removing registries just doesn't work. I'd like to do this for 1.5 if I can get everything done in time.

@StefanKarpinski
Copy link
Collaborator

Oh, this also removes any need for special casing General: instead we make pkg.julialang.org the default pkg server and when users connect to that, they get General "for free".

@GunnarFarneback
Copy link
Contributor

It looks to me like the /registry resource effectively already advertises which registries are available and that everything else are Pkg features?

@StefanKarpinski
Copy link
Collaborator

Yes, this is more of a Pkg issue.

@GunnarFarneback
Copy link
Contributor

I guess I'm a little slow on the uptake. So the /registry resource will only give direct information about the registry UUIDs, and currently the only way to add a non-General registry from a Pkg server is by UUID? Well, if that's the case it's not gonna fly. How can I help get this off the ground?

@StefanKarpinski
Copy link
Collaborator

The notion is that you set your pkg server—or use pkg.julialang.org by default—and the pkg server advertises which registries is serves—in the case of pkg.julialang.org only General. The client would automatically install any registries advertised by its current pkg server. The client could also automatically update any registries installed as git repos since it can do so by git pulling them and they were presumably manually installed (except for legacy General registries). This arrangement largely moves management of what registries to look in from the client to the server.

@GunnarFarneback
Copy link
Contributor

Yes, that plan sounds good. I'm more wondering about what can be done to make it a reality sooner rather than later. Or is this earlier comment

I'd like to do this for 1.5 if I can get everything done in time.

already under control?

@StefanKarpinski
Copy link
Collaborator

I've been doing a major Pkg rewrite from the resource acquisition layer up, but it's not going to be ready in time for the 1.5 feature freeze, so I'll have to pause that and figure out where to add this functionality in the current architecture this week.

@GunnarFarneback
Copy link
Contributor

I have a working PkgServer set up now that serves General and a private registry, so I can at least help with testing a solution. On 1.4 it does work to do registry add by UUID, but that's obviously not so convenient.

@fredrikekre
Copy link
Member

registry add with no arguments could install all known registries.

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