This past Friday GitHub made a major announcement that they have created a new package registry.
Regular Dev contributor and all-around awesome human, Tierney Cyren, live tweeted the event and you can catch up on his twitter thread:
Tierney Cyren ✈️ GitHub Special Event 💖@bitandbang
- Full integration with GitHub
- Public and private registries
- npm, gems, nuget, maven, Docker, + more shipping20:39 PM - 10 May 2019
There seems to be a lot of reaction in the JavaScript and Node communities. My question is what does this mean for Ruby devs? Does this have any implications for our work and workflow? Does this interact at all with RubyGems?
Would love to hear your thoughts!
Top comments (13)
Since RubyGems.org I’d a non-profit and GitHub is a Ruby shop, I’d predict that RubyGems.org won’t try and be overly competitive and that the GitHub registry will eventually become the dominant one.
I hope RubyGems.org lives on and provides a good service, but I definitely think that the Ruby community could shift to GitHhb.
On the other hand, new Ruby projects aren’t spinning up at the same pace that JS one’s are. So the majority might just stick with what they have unless GH can make some radical improvements in security or elsewhere.
GitHub package registry is not a single registry. Every user/org has they own isolated registry. So you will have to explicitly declare every registry so that it can be used in your project.
And how will the dependency manager know which registry is the authorative registry for a given package?
That's a really good question.
Definitely agree with a lot of that! It was interesting to me that from the start Ruby is a considered language in the new registry, but then I remembered that GH is a Ruby shop and then it all made sense. :)
Do you think, from what you've read so far, that there would be any advantage to moving existing projects to the new registry? There aren't a ton of new Ruby gems annually (although there are some!) so it's mostly I think about maintenance at this point.
RubyGems and Crates are 2 of the most hassle free package registries I've ever used. I don't think GH is becoming the biggest anytime soon
Yeah I agree on that count
I love working with RubyGems. So intuitive and easy.
I don't see it replacing RubyGems.org or npmjs.com anytime soon. It could be useful for some open source projects (maybe as a beta/prerelease repository?) but since it's scoped to a single user/organization I think it will be more useful for private packages.
I surely see a nice use case for it here at Mikamai, where I work, since we have some private gems that we cannot release as open source for legal reasons, and we have to download them via Git using access tokens. Being able to use our GitHub accounts with the same ACL as our GitHub org would be wonderful!
I'm not sure if I think it will have a major impact on public registries, but I think it's big win will be private registries.
It'll be a way to distribute private gems that are currently private GitHub repos. Specifying dependencies as git dependencies has downsides so I could see organizations use private registries to share these gems.
That's an interesting benefit. I can see how that could be helpful for specifying the gem dependency for a non-public gem.
We use GemInABox in Proxy mode.
github.com/geminabox/geminabox
I have concerns. Fragmentation and Privatisation
Fragmentation. Devs will ask which one should they use and before you know it there will be confusion. Not good.
Privatisation. Let's not forget Github/Microsoft are ONLY in it for the money. I'm guessing they're hoping that more devs will subscribe to paid plans - money.
In the same theme, I am thinking about centralization. Every service has its outages and the more that is tied into that one service, the more that is impacted when that happens.
Re: the money topic -- I'm torn on that one. If we accept the argument that they are in it only for the money, you could still say providing the best customer experience is in their monetary benefit, especially in a competitive marketplace, no?