Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gnuu.org

Post reply on HN
Print view View original

21–30 of 41 posts

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

#21

Post by nirvdrum »

uncle_jabber wrote: post #20
jcapote wrote: post #9

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

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 h…

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.

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

#22

Post by sandal »

kennystone wrote: post #19

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.

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

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

#23

Post by uncle_jabber »

uncle_jabber wrote: post #20
jcapote wrote: post #9

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

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 h…

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

Strike my "0.8.7 to 0.9.0" rationale.

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

#24

Post by holman »

kennystone wrote: post #19

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?

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

#25

Post by sandGorgon »

wheels wrote: post #6

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 c…

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.

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

#26

Post by sandal »

holman wrote: post #24
kennystone wrote: post #19

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.

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

#27

Post by lindvall »

sandal wrote: post #15

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…

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?

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

#28

Post by sandal »

lindvall wrote: post #27
sandal wrote: post #15

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…

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 up…

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 RailsRubyGems members in the future.

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

#29

Post by endgame »

jrockway wrote: post #18

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 thi…

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

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

#30

Post by rbranson »

uncle_jabber wrote: post #20
jcapote wrote: post #9

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

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 h…

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.
Post reply on HN