Live data from Hacker News

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

gnuu.org

31–40 of 41 posts

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

#31

Earlier quoted context omitted.

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.

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?

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

#32
post #24

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?

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

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

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

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

#34
post #32
post #24

Earlier quoted context omitted.

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

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

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.

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

#36

Earlier quoted context omitted.

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.

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.

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

#37
post #14

Earlier quoted context omitted.

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.

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?

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

#38

Earlier quoted context omitted.

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.

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.

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

#39

Earlier quoted context omitted.

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

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.

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

#40
post #12

Earlier quoted context omitted.

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