Yes, I totally did. I do apologise. I did now re-read the proposal and I can confirm that it doesn't mention that you can configure additional registries (which I was just assuming to be true, apologies). However, it also doesn't mention that you cannot add registries. Which especially given that it mentions search (at the very bottom) I find surprising.
I think that would help. Also would it help to explicitly spell out "No, you can't configure your own registries."
Knowing what I know now, I think I have much graver concerns.
Assumptions:
- As a user, I cannot manually configure registries.
- To benefit from the package "registry" feature, the selected git host for a certain package will ALSO need to (correctly) implement the SwiftPM registry protocol.
If the above is correct, then I have a bunch of questions:
- How does the bootstrapping work? I understand that Github was involved and are willing to implement this. What are the timelines? What do we do before Github has implemented this?
- How does one enable registry support in Github? Is it on or off by default?
- Once Github has implemented the feature, how do we get bugfixes if they mis-implemented something? Will the code be open-source at least?
- What about the people who don't have (or can't have) a Github account?
- Are we expecting people that use say Gitlab to also create a repository on Github just so their package benefits from the registry feature?
- If it is the case that to start with everybody should have a Github repository to benefit from this feature, do the package authors now also need to convince all of their users to enter
https://github.com/my-org/my-package-just-here-for-the-registry
despite the fact that they're actually hosted athttps://my-skunk-works-git-host.com/swifty-awesome/swifty-awesome
? - What if Github or another git host decommissions its SwiftPM package service for some reason? Are we then expecting everybody to move elsewhere? If yes, how does the forwarding now work given that the registry service was just shut down?