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.
SlimGems, a drop-in replacement for RubyGems -- now available
11–20 of 41 posts
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#12RubyGems 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 c…
Don't forget rake. The latest version of rake broke all versions of Rails (don't know if this got fixed yet).
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.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#13We 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…
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 decid…
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.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#14Earlier quoted context omitted.
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…
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,…
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.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#15Before 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
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#16Having 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.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#17Earlier quoted context omitted.
Don't forget rake. The latest version of rake broke all versions of Rails (don't know if this got fixed yet).
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/
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#18Packaging 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.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#19If 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.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#20RubyGems 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 c…
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.