GitHub Package Registry: What Does It Mean For Ruby Devs?

twitter logo github logo ・1 min read

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:

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!

twitter logo DISCUSS (13)
markdown guide

Since I’d a non-profit and GitHub is a Ruby shop, I’d predict that won’t try and be overly competitive and that the GitHub registry will eventually become the dominant one.

I hope 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?


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


I love working with RubyGems. So intuitive and easy.


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?


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.


I don't see it replacing or 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!

Classic DEV Post from May 26

How to Stay Fit Physically and Mentally and Keep Coding

Throughout the last year, I have worked part-time as a working student and also studied at the university. I was not the first and not the last one who has combined that during their studies, but the problem for me was, that at the end of the day I have felt absolutely exhausted mentally and physically. That caused problems with my health and motivation to continue working on my goals or anything. (yeah, β€œgoals,” I wish I had something more specific at that time).

Ben Greenberg profile image
Rabbi turned Coder. Second Career Dev taking it one function at a time.