[steveklabnik]

This may sound a bit glib, but the reason it's so slow is because basically every Rubyist goes "Does anyone know why installing gems is so slow? What is this thing doing?" And then _takes a coffee break instead of figuring it out_.

There are very, very, very few people who actually do any work on core infrastructure projects. I don't blame them. The codebase of rubygems is... not exactly welcoming. I myself did some work a while back, got frustrated, and quit. But if you want the real reason, there it is.

Oh, and when you _do_ overcome all these barriers and then actually make an improvement, people will say "lol rubyists learning data structures" instead of saying "thank you for saving a bit of the most precious resource I have every single day, time."

[mbrock]

Yeah, good point. Still, it seems likely that a number of people have done at least some work on profiling and optimizing without success. Hasn't Gem slowness been an issue since, like, 2006? The reason I haven't even tried is mostly that it seems likely to be difficult and treacherous. But I might be wrong.

Note that I wasn't only complaining. I just figured that there is some real reason for the slowness and that this reason might be known by the community (and I didn't find much googling for "why is ruby gems slow"). Call it preliminary research...

[steveklabnik]

> Still, it seems likely that a number of people have done at least some work on profiling and optimizing without success.

You'd think that, wouldn't you? The reality is... not that. :/

And yeah, this isn't really about you specifically, sorry if it came off that way. This is just a general problem in the Ruby OSS world. I can't speak to too many other OSS worlds, as the Ruby one is the one I've been most involved in. If you're looking for more research, Andre Arko is one of the other people who's actually doing work in this area, and he's given a number of talks about why Bundler is slow: https://vimeo.com/67807956 and related. He's been making a lot of strides, but it's not easy.

[mbrock]

Cool, thanks, that's good info! I'll have to investigate these talks.

[moe]

The codebase of rubygems is... not exactly welcoming.

What a very polite way to put it.

IMHO that whole mess (rubygems + bundler) would ideally be replaced from scratch, removing the need for bundler in the process.

If any generous sponsor wants to improve Ruby as a whole, that's where their money should go. Imagine the productivity gains if everyones test-cycle was suddenly >10% faster, and nobody would have to waste energy on bundler/rbenv/rvm issues anymore.

Perhaps we could even fix the deployment nightmare in the process, with e.g. jar-style packaging, but now I'm really dreaming...

[steveklabnik]

I may or may not have threatened to do this after having had one too many drinks, but when I sobered up, I... sobered up. ;)

While I love a good 'burn the world down re-write,' it's a _lot_ of work and isn't guaranteed to succeed. It's been tried before, and in other languages too: check out wheels in Python.

That said, Rubygems did replace what came before it, and Gemcutter replaced what came before it... so it could be done. It's just non-trivial.

[moe]

I... sobered up.

Same here, still have my napkin notes. It's actually one of my bucket list projects, if there wasn't the dreadful food-on-table constraint...

check out wheels in Python.

Valid point. Python is indeed a good example for an even worse situation. In fairness, most languages are still worse off than Ruby even now. I wouldn't trade maven, CPAN, etc. for bundler with all its warts.

However, there's also languages pulling ahead. npm seems to be slowly getting there (after a rough start) and the Go experience (godep), while still in flux and not directly comparable, is also something to draw lessons from.

[riffraff]

I'm reasonably sure some of the rubygems maintainers stated that in $FUTURE_VERSION bundler's functionality will be folded back in rubygems itself.

Rubygems is a very old project and it was basically stalled for a long time, it has already made quite big strides recently.

But I don't think it's rubygems' role to fix what rvm/rbenv fix (multiple rubies). Jars don't do that either :)

[moe]

But I don't think it's rubygems' role to fix what rvm/rbenv fix

Well, it all sticks together. I would say ruby-build should be retained as an external tool to conveniently fetch and install ruby versions.

However, we should very much replace the god awful environment magic that rbenv/rvm perform with native ruby/rubygems support for version/project-scope gemsets.

Rbenv is a well designed crutch - but still a crutch.

In an ideal world you'd checkout a ruby project, point any recent ruby-binary at its Gemfile, and it would download/install not only the required gems, but if necessary also the required Ruby version, as specified by the Gemfile.

It would store everything in './.ruby', which could optionally be backed by a common shared directory (~/.ruby) for space efficiency.