[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.