The Missing Bundler Features

5 points by jez


soulcutter

I do think that pessimistic version / upper constraints can often be a problem, and maybe the force: true idea would be a nice escape hatch.

I'm less convinced about substituting gems, I can imagine that becoming a mess over time very easily. The discussions around it proposed an experimental feature, and I don’t see that it materialized, which gives me the feeling that the implementation complexity is high.

One of the suggestions in the Bundler RFC was the introduction of a scope: “shopify” style of supplying a gem from a different source, which I think is less-complex and easier for me to reason about.

The CIs of big Ruby companies actually hit rubygems.org much less than even a small project CI with no cache would.

Mayyyyybe. I’m skeptical, I think there’s a lot of inefficient usage, bad or no caching, no private gemserver mirroring, etc. The companies that Jean has worked at may have solved this, but I’d bet it’s not true across the board. And in some ways it doesn't matter: if it isn’t the big companies, it's the smaller ones, and if they have outsized usage then why shouldn't they incur cost? Back to the thrust of the article, if small companies would benefit from speed improvements without having the sophistication to have caching, isn't that good too? There’s more small organizations than big ones.

I do think these are some real points of friction, and it’s worth investing in improvements, and it feels like that aspect of bundler has been neglected. Personally, I’m open to switching tools to get speed improvements AND usability ones.