
SlimGems, a drop-in replacement for RubyGems -- now available - bcardarella
http://gnuu.org/2011/06/01/slimgems-a-drop-in-replacement-for-rubygems/
======
sandal
Before you make a decision for or against SlimGems, please be sure to check
out my series on RubyGems, in particular note the following things that
happened in the last week:

* RubyGems now promises to stay API compatible with whatever version of gems ships with the latest point release of Ruby 1.9. That means if RubyGems 1.8 ships with Ruby 1.9.3, the RubyGems 1.8 API will be preserved at a minimum until Ruby 1.9.4 comes out, which will be no sooner than 6-18 months from now.

* RubyGems has removed two deprecation warnings in 1.8.4 and 1.8.5 that account for virtually all deprecation warnings that were frustrating users.

* Bundler works out of the box on RubyGems 1.8, as does Rails 3. The next point release of Rails 2.3 will also support RubyGems 1.8. Evan Phoenix is a maintainer of both RubyGems and Bundler, and is taking the responsibility of cutting stable releases of RubyGems for the time being, which nearly guarantees there will be no further Bundler issues.

* Frequent point releases of RubyGems should hopefully be a thing of the past, because starting with RubyGems 1.9, there will be beta and release candidates running for a month long cycle before they get shipped as stable releases that get installed by gem update --system

You can find additional information here:
<http://blog.majesticseacreature.com/tag/rubygems>

~~~
lindvall
So far I'm not really a fan of forking RubyGems, but I am concerned with the
solution you mentioned for compatibility with Rails (which I take as a good
metaphor for any large Ruby project) — a new point release. How is that going
to work for people on Rails 2.2 or other projects with incompatibilities?

Has anyone discussed emailing the authors specified in the gemspecs of the
gems that will be breaking with these upcoming changes?

~~~
sandal
What Bundler does is run CI against RubyGems so they get automatically
notified of issues. It seems like Rails should possibly consider doing that as
well. However, there seems like there will be more communications between
Rails<->RubyGems members in the future.

------
wheels
RubyGems 1.8.5 actually breaks _Rails_ 2.3.11. Just to be really clear there:
the package manager breaks the 4 month old release of the most important
framework for that language, on a branch that until rather recently was still
the preferred production stack (and is still used by a bazillion websites).

I was flabbergasted. Really? Nobody thought to check to make sure the package
manager release doesn't break Rails 2 _completely_? I'm glad to see Loren and
crew step up.

~~~
jcapote
Don't forget rake. The latest version of rake broke all versions of Rails
(don't know if this got fixed yet).

~~~
uncle_jabber
Well for rake the breakage was intentional. The Object class shouldn't have
been littered with the rake API. After all it was 0.8.7 to 0.9.0.

In Rake 0.9.1 the global API is back, but with warnings this time.

The rake 0.9 beta was out for months, so I am surprised that something as high
profile as rails got broken. While framework maintainers are ultimately
responsible for their own stuff, the rake maintainer could have pro-actively
made an announcement to the effect of "Hey, look out!"

In an ideal world, a continuous integration thingamabob would have sent an
alert to rails maintainers about the breakage with the rake beta.

~~~
rbranson
There seems to be an attitude problem in the Ruby community,. Lots of prima
donnas who don't want to work together or work with those outside their
clique. It is self-perpetuating as well. I'm sure part of the reason some
projects isolate themselves is because they've tried and been given the cold
shoulder or ignored. Zed isn't completely off base about this.

~~~
Confusion
Having worked exclusively with Ruby for the last 14 months, and comparing
things to the situation with Java or Python libraries, I completely agree with
this. Working with Ruby gems is often very frustrating. Core libraries like
Rubygems, Bundler, Rake and even Rails often cause an application to break
when they are upgraded. Minor upgrades _regularly_ cause breakage, where that
would be a rare exception with Java or Python libraries. Major upgrades
_usually_ cause breakage, where others would strive for backwards
compatibility from the start and often succeed. All the benefits I perceive
Ruby to have, all the time I gain by progamming in Ruby, I lose to unnecessary
library issues. I'm at the point where I advise others to seriously reconsider
their choice when they intend to do a new project in Ruby.

~~~
grunk
Your story has some errors which, when coupled with the hyperbolic
exaggerations, make me believe your story is a fabrication. For example Rake
wasn't updated for two years until the very recent 0.9, so that part is a lie.

You can recover some credibility if you can tell us specifically which minor
upgrades caused breakage. You'll have to list a bunch of them in order to
support the "regularly cause breakage" claim.

However I'm certain you won't be able to do that. Go troll somewhere else,
please.

~~~
Confusion
Yeah, that's the kind of attitude that has allowed this situation to persist
for so long. Quibble about details when the bottom line is that I don't dare a
minor upgrade of even the smallest gem for fear of having to spend a day on
some wild goose chase. So perhaps Rake was never responsible for any of the
breakage. I misremember or misattributed: so what? It doesn't matter, because
I don't trust Rake either. You want examples of other breakages? Follow Some
of the mailing listst and Google groups. Stuff breaks a zillion times more
often than in the Java and Python communities.

------
holman
I'm all for projects like SlimGems. You can be a cowboy in your app, you can
be a cowboy in your framework, you can even be a cowboy in your _language_ ,
to some extent. But package management should be as absolutely rock-solid and
considerate as possible. RubyGems has been anything but. Patch versions
introducing breaking changes, outwardly hostile deprecation warnings, and some
fairly hostile developers. There needs to be more attention paid to Semantic
Versioning (<http://semver.org>) and less breaking.

~~~
nirvdrum
Just a small distinction: semantic versioning does nothing to prevent you from
breaking, it just take the high road by calling it a different version number.

My big issue with semantic versioning, which I endorse on the whole, is that
it says it's okay to change public interfaces between major versions. That's
fine if your environment allows you to activate two different versions of a
library, but most don't. In this case, it means even if RubyGems was called
2.0, you'd have the same technical problems if you have libs with dependencies
on RubyGems 1.x and other libs with dependencies on RubyGems 2.x. Modules
really should be used to namespace interfaces across major versions.

~~~
holman
The whole point of versioning, however, is to designate how big changes are
between versions. There's a world of difference between 0.2.1 to 0.2.2 versus
0.2.1 and 0.3.0. _That's_ what I'm mostly concerned about- patch versions
should be a relatively low-stress change between versions. Changing that minor
or major number to designate something large is coming is important.

I agree that it doesn't necessarily mean that you won't have to rework your
local code, but particularly with projects like RubyGems (which are more end-
user than code integration points), it's more important to know whether or not
upgrading will break your entire process.

~~~
nirvdrum
It's important as a communication tool. But you'd still be in a world of hurt
because that logical distinction doesn't affect execution semantics. The
problem is exacerbated once transitive dependencies enter the picture.

As a concrete example, the redis-rb gem went to 2.0 and completely broke API
compatibility. They did everything right by the semantic versioning book. I
used about 10 libraries built atop redis-rb, but never used redis-rb directly.
About half the libs updated and required the use of redis-rb 2.0, the other
half did not. Moreover, the gem dropped protocol support for the old redis-
server, too, so it forced a redis-server upgrade.

This was an absolute mess to work out because updating 10 libs at once is
basically insane. And the whole thing could have been avoided if modules were
used to namespace, allowing activation of both sets of classes.

But, anyway, this isn't to say semantic versioning has no value. It's just not
a solution to a library that keeps changing its public API either.

~~~
qrush
RubyGems doesn't follow SemVer, it follows Ruby's versioning system. :(

(offtopic) Also, I too got bit by the redis-rb changes. They also broke apis
from 2.1 => 2.2 as well. SemVer isn't hard, I don't understand why people
can't follow it.

~~~
FooBarWidget
Hm? RubyGems doesn't enforce any particular versioning system, packagers to
free to use semantic versioning. Or are you talking about RubyGems itself and
not RubyGems packages?

------
tomdale
We have been working on several JavaScript-related tools that build on top of
RubyGems. The most recent versions of RubyGems issued what were, IMO, user
hostile deprecation warnings, which confused and alarmed our end users. We
were not aware of these changes ahead of time, and it didn't seem to be of
much concern to the RubyGems maintainers.

For critical infrastructure like package management, these kind of changes can
be difficult to deal with. We're switching all of our projects to SlimGems,
and are going to be contributing code for improving its use as a library for
other software to build on.

~~~
nupark2
The Ruby/Rails way: When the drama created by oversized egos inevitably comes
to a head, fork/replace the project and badmouth the other guys.

Allow me to rewrite your statement to be ruby-drama-free:

We have been working on several JavaScript-related tools that build on top of
RubyGems. As the most recent versions of RubyGems have begun deprecating
standard APIs that we and many other projects rely on, we have decided to fork
the project, with the intention of maintaining an alternative to RubyGems that
maintains ongoing compatibility with the existing API.

<optional: insert rational for forking / discussion of how you would prefer to
merge and not use the nuclear option of forking someone's project here>

~~~
burke
People love to create meta-drama about the ruby drama, but really, let's not
sugar-coat it. These are significant and serious breaking changes to the
standard package manager, in a point release. Something is wrong.

------
jrockway
Packaging is one of those things like indentation style and text editors:
nobody can ever agree.

I know this is mostly designed to be Internet Drama ("I've saved the Ruby
community from the RubyGems Cowboys! Yay for me! I'm cooler than _why!!"), but
the reality is, everyone wants their own package manager. Every Linux
distribution has their own. Perl has three CPAN clients, two of which are in
the core!

Anyway, I think this is supposed to be a Big Deal, but it's not.

~~~
endgame
Unlike brace style, package management is an NP-complete problem. See
<http://www.edos-project.org/xwiki/bin/Main/Deliverables> , with further
reading at <http://www.mancoosi.org/papers/> .

------
kindlyviking
I'd love to see slimgems also make it easier to install and manage gems
programmatically (without the CLI). Using the internal rubygems classes
yourself is... frustrating.

------
sgrock
I'm really happy to see SlimGems released. In addition to the deprecation
warnings and lack of backwards compatibility, there's been some major
performance degradation in recent versions of rubygem (e.g.
[http://rubyforge.org/tracker/?func=detail&atid=575&a...](http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126)).
It's about time someone offered an alternative.

------
ghempton
Having not felt the pain, based on the website I really don't know why to
switch. Guess I'll either wait for the incompatibility issues or a compelling
reason.

------
kennystone
If this is the big complaint (from the slimgems site):

"Deprecations would not mean warning messages or method removal. We will work
with the community to make sure library developers upgrade their code on a
convenient time frame for everybody (years, not months), and that nothing
breaks. No rush!"

Then it's the kind of lesson that can be learned from and fixed. No need for
forks.

~~~
holman
> Then it's the kind of lesson that can be learned from and fixed. No need for
> forks.

I agree. But, to be fair, it's hard to hope for the project to be improved and
fixed when someone responsibly brings up the issue on the RubyGems issue
tracker and gets the following response from a RubyGems developer:

> Really? Don't you have anything better to do than to post inflammatory shit
> to this tracker?

~~~
saurik
Did you read the way that issue was worded? Whether you agree with what that
issue reported or not is irrelevant: it was intentionally written in a way to
be "inflammatory", and I have nothing but respect for someone (the developer)
that will call people (the reporter) out like that (although part of me wants
to say "don't feed trolls").

(Note: I read your message, know nothing of these people involved, and simply
searched to find the issue as I wanted to actually see what had "gone down"
for myself: that bug report, despite the fact that I don't even /use/ Ruby,
"riled me up", which says something pretty bad about its intent.)

~~~
holman
I think he had a valid issue and brought it forward in a responsible manner.
He's trying to teach Ruby to a classroom of beginners and the first thing you
have to tell them is to ignore hundreds of lines of scary-looking deprecation
notices every time they run a valid and correct command. That's not what
should be happening. The title may have been a bit facetious, admittedly (I
didn't notice it at first due to the mess that is RubyForge), but the actual
issue body was straightforward.

------
pspeter3
I'm glad I never upgraded to see these issues and that someone is taking care
of them

------
cultureulterior
What about debian package compability?

