5 ms·

SlimGems, a drop-in replacement for RubyGems -- now available

94 points by bcardarella 15y ago

kennystone 15y ago
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.
- sandal 15y ago
  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-management-policies-for http://blog.majesticseacreature.com/establishing-release-man...
- holman 15y ago
  > 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?
  - sandal 15y ago
    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.
  - saurik 15y ago
    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 15y ago
      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.
tomdale 15y ago
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 15y ago
  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 15y ago
    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.
holman 15y ago
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 http://semver.org) and less breaking.
- nirvdrum 15y ago
  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 15y ago
    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 15y ago
      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.
wheels 15y ago
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 15y ago
  Don't forget rake. The latest version of rake broke all versions of Rails (don't know if this got fixed yet).
  - uncle_jabber 15y ago
    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.
    - nirvdrum 15y ago
      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.
    - uncle_jabber 15y ago
      nirvdrum, you're right, it should have been a change for rake 1.0. Strike my "0.8.7 to 0.9.0" rationale.
pspeter3 15y ago
I'm glad I never upgraded to see these issues and that someone is taking care of them
kindlyviking 15y ago
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.
sandal 15y ago
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 http://blog.majesticseacreature.com/tag/rubygems
- lindvall 15y ago
  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 15y ago
    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.
ghempton 15y ago
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.
jrockway 15y ago
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 15y ago
  Unlike brace style, package management is an NP-complete problem. See http://www.edos-project.org/xwiki/bin/Main/Deliverables http://www.edos-project.org/xwiki/bin/Main/Deliverables , with further reading at http://www.mancoosi.org/papers/ http://www.mancoosi.org/papers/ .
sgrock 15y ago
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&aid=29116&group_id=126 http://rubyforge.org/tracker/?func=detail&atid=575&a...). It's about time someone offered an alternative.
cultureulterior 15y ago
What about debian package compability?

94 points by bcardarella 15y ago

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.

sandal 15y ago
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-management-policies-for http://blog.majesticseacreature.com/establishing-release-man...
holman 15y ago
> 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?
- sandal 15y ago
  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.
- saurik 15y ago
  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 15y ago
    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.

tomdale 15y ago

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

holman 15y ago

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 http://semver.org) and less breaking.

nirvdrum 15y ago
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 15y ago
  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 15y ago
    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.

wheels 15y ago

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 15y ago
Don't forget rake. The latest version of rake broke all versions of Rails (don't know if this got fixed yet).
- uncle_jabber 15y ago
  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.
  - nirvdrum 15y ago
    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.
  - uncle_jabber 15y ago
    nirvdrum, you're right, it should have been a change for rake 1.0. Strike my "0.8.7 to 0.9.0" rationale.

pspeter3 15y ago

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

kindlyviking 15y ago

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.

sandal 15y ago

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 http://blog.majesticseacreature.com/tag/rubygems

lindvall 15y ago
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 15y ago
  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.

ghempton 15y ago

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.

jrockway 15y ago

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 15y ago
Unlike brace style, package management is an NP-complete problem. See http://www.edos-project.org/xwiki/bin/Main/Deliverables http://www.edos-project.org/xwiki/bin/Main/Deliverables , with further reading at http://www.mancoosi.org/papers/ http://www.mancoosi.org/papers/ .

sgrock 15y ago

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&aid=29116&group_id=126 http://rubyforge.org/tracker/?func=detail&atid=575&a...). It's about time someone offered an alternative.

cultureulterior 15y ago

What about debian package compability?