Hacker News new | past | comments | ask | show | jobs | submit login
SlimGems, a drop-in replacement for RubyGems -- now available (gnuu.org)
94 points by bcardarella on June 2, 2011 | hide | past | favorite | 40 comments



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


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?


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.


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.


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


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.


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.


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.


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.


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.


The western Ruby community is well observed phenomenon and opinions abound, but does anyone know if it's been formally studied? Anyone on HN with a strong psychology background have any insights?


No.

That would spoil the fun of make sweeping generalizations about thousands of people based on the behavior of a few.


While the breakage may have been intentional, it was still ill-advised. Littering the Object class was indeed bad form, but it's been that way for years and everyone's coped with it just fine. Breaking every Rakefile I came across (and they weren't all Rails) to correct the sins of the past doesn't really build confidence in a tool that was at a de facto 1.0 release, even if they were reluctant to call it that.


nirvdrum, you're right, it should have been a change for rake 1.0.

Strike my "0.8.7 to 0.9.0" rationale.


Rake 0.9.1 is out, but I haven't had a chance to test it. I can't even find where on earth it's being maintained now.


It shows right on the homepage for Rake (http://rake.rubyforge.org/):

Rake is currently hosted at github. The github web page is http://github.com/jimweirich/rake/


Cool, thanks. The first Google SERP for "rake changelog" was kind of awful.


question - does JRuby follow the same versioning and release cycle as vanilla Ruby, including Rake, Gems, etc.

Essentially, what I mean to ask is if this kind of breakage is expected in JRuby anytime soon.


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.


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.


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.


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.


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.


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?


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.


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>


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.


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.


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


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.


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...). It's about time someone offered an alternative.


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.


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.


> 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?


There have been personal conflicts abound in this drama around RubyGems, and that's a big part of the problem. The solution that I've come up with in my talks with the RubyGems maintainers is that anyone who feels that they can't work with Eric and Ryan (or vice versa) will be able to talk to Evan, who has less of a track record of difficult interactions with users.

No, that's not a great solution. But neither is supporting a fork by someone who's been working on this for three weeks when the current RubyGems core team has members on it with over 4 years of experience with the codebase. At the very least, this needs to stop being emotional and the technical points need to be laid out cleanly on white paper.


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


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.


I agree, in fact, it's not even a problem that isn't already being worked on. Here are the new release policies from the RubyGems team:

http://blog.majesticseacreature.com/establishing-release-man...


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


What about debian package compability?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: