Yehuda lays out some of the history and rationale behind Rubygems’s multi-package-version design and also takes a look at how a few recent tools (Bundler, Rip, rvm, etc.) are using different approaches to develop concepts around multiple “environments”.
I’ve never been a fan of Rubygems multi-versioned, directory-per-package approach to organizing packages. There’s a few different reasons, but mostly it forces a lot of unnecessary complexity into runtime that could (I think) be handled more simply at install time. I do like the convenience of installing a bunch of packages into a single Rubygems environment without having to think about it, but those benefits are outweighed by the subtle differences in runtime behavior, some of which can be extremely annoying (e.g., “already activated” errors). I’d rather be aware of and be forced to deal with those issues at install time. It’s great to see so much experimentation on new tools and alternative approaches.
Gemcutter will become rubygems.org and Rubyforge will eventually go away entirely:
So, what does this mean for RubyForge? The Ruby-specific functionality and data will be moved into RubyGems.org, and the parts that other hosting sites (GitHub, Google Code, SourceForge) can do better will be pruned away. Migration paths for those projects will be provided, we’re not throwing any switches without warning. RubyGems.org will not be gaining any “bloat” from rewritten RubyForge features.
Wow. Congrats to @qrush and the Rubyforge team for pulling this off so quickly. Also, it’s pretty cool to see Heroku hosting a major/official piece of Ruby community infrastructure.
Nick Quaranto shows why you need to start thinking about bundler.
This is an interesting idea. Publishing gems on rubyforge is complicated but the gem source is everywhere and gems have sane file names. Publishing gems on github is dead simple but the filenames include a username prefix, which is just kind of weird. Publishing gems to gemcutter is simple enough and the gems have sane filenames. This could work.
An interesting RubyGems mod by Fabien Franzen that seems to fix the memory hit a process takes on require 'rubygems'. Unfortunately, you have to code for it in your app and apply it to installed ruby commands explicitly. Fabien has submitted a ticket and patch to the RubyGems project, however. You should +1 it (after reviewing the code, of course).
Yep. Rubygems’s system of security is really very lax compared to any Linux distro or other system-level package management system I’ve come across. I think the bigger problem, though, is that there’s a cultural acceptance to running gem as root. You don’t really think before installing a gem, you just “sudo gem install FOO”. There’s an attack waiting to happen any time you’re using sudo out of convention like that.
A gem for your project is automatically built each time the project_name.gemspec file is changed on your master branch.