Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I personally cannot think of a new ruby gems or bundler feature from the past decade that I noticed or cared about. That isn't to say that there aren't any; I just don't know what they are.


There have been several releases with incremental but still notable performance improvements. The overall cadence has been pretty steady, intentionally targeting roughly one minor release per year since 2019-ish, with handfuls of quality of life improvements in each. Arguably RubyGems and Bundler are infrastructure, so the major feature is stability. What sort of big feature are you imagining is missing from your dependency management system?


André is working on a combination of rbenv/asdf, bundler, and gem that I think is interesting. Not that they're wildly broken, but I'd rather have fewer tools and it always seemed a bit odd that they're separate when they're notionally managing the environment in which your ruby code executes.

Given the rise in supply chain attacks, I'd also like a private rubygem instance where I can whitelist gems and even versions for my company in a way that doesn't let anything else install. I'm not sure if they're taking that on or not, but I'd like it.

the rv thesis is here: https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-mana...


> I'd also like a private rubygem instance

that was always possible https://guides.rubygems.org/run-your-own-gem-server/

(there's also "gem server")


That's basically my point. I'm not missing anything, so I'm happy if it just gets small / stability fixes, which doesn't seem like it needs a six member maintainer group. That team should go off and do a great job with 'rv' or whatever the next brand new idea is, and just let rubygems sit there with minor updates, same as we do for the ruby logger or date class.


It seems unrealistic to believe that packaging infrastructure can just “sit there,” particularly in light of changing expectations around the bare minimum a packaging ecosystem should do to protect its users. I think a more reasonable assumption would be that the (former) RubyGems team did a good job, which translated to boring normality for you.


> so I'm happy if it just gets small / stability fixes

Seems like you're the ideal consumer for this new service, since it actually has people who can do that.


I think I basically agree with this, but my thoughts are more on which org is better placed now to respond to things like the recent supply chain attacks (ref for the specific recent ruby one[0][1]).

I'm unsure on who is better placed to handle that stuff now. My view is that the people that were doing that are now with gem.coop, but rubygems still has the infra (i.e. you'd email security@rubygems.org still for now).

I'm unsure about what to think about longer term (my personal approach is currently "wait and see").

Similarly, I'm perfectly happy with bundler for now, but if `rv` turns out to be like `uv`, I'd happily switch (drop-in replacement, but faster/some better features).

[0] https://www.bleepingcomputer.com/news/security/60-malicious-...

[1] https://blog.rubygems.org/2025/08/08/malicious-gems-removal....


Socket.dev states "Since at least March 2023". RubyGems says "Our team first detected this activity on July 20th". This attack has ran for almost 5 months undetected. I wouldn't feel reassured at all.


Lockfile checksums are quite new and useful.


They made bundler output compact, previously it spammed all installed versions and updates mixed, now you can see just updates if you do those for example.. or quite concise "all OK" if everything is as it should be. Small but really nice quality of life change imo




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: