4 ms·

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 fr

by moe 12y ago

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 12y ago
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 12y ago
  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 12y ago
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 12y ago
  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.

by moe 12y ago

steveklabnik 12y ago

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 12y ago
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 12y ago

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 12y ago
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.