9 ms·

Giving up on Ruby packaging

92 points by philf 16y ago

pkulak 16y ago
I've never had very good luck using the Ubuntu Ruby packages. The binaries are never linked, and I can't update Rubygems, which means I can't install a lot of gems that I need. Is it tough to use RVM on a production server? Is it easy to get Thin setup and all that?
thmzlt 16y ago
The same thing happened to Gentoo. I talked to the people behind Ruby packages in Gentoo and they wanted to manually create packages for each gem. It is one of the main reasons why I gave up on Gentoo and went back to Arch Linux. I see gems as just snippets of code instead of "real" OS packages. They change a lot, they are application specific, and (most of the time) they are simple.
- davidw 16y ago
  > I see gems as just snippets of code instead of "real" OS packages. They change a lot, they are application specific, and (most of the time) they are simple. And, like me, if you're using Rails, they are code that is visible to the outside world. That is code that you want to make sure is secure, and is not just some minor detail.
grimen 16y ago
Evolution is key: Survival of the fittest, and RVM is the fittest in my experience.
davidw 16y ago
I started using RVM a little while ago, and... I am not that excited about it (although it is well done and mostly works as advertised). It seems like the direction Ruby is going is to have things like Rails applications that require their own version of Ruby and a whole slew of gems, which also means that if you have a number of applications, you start getting a large amount of duplication? I'm not entirely sure as I'm new to the system, but it adds an extra level of installed stuff that I'm not 100% comfortable with. Edit: as an aside, Zed Shaw's wild attacks and untruthful accusations against Debian were some ugliness that the world could have done without. I hope Lucas finds other places to more productively (and happily) employ his talents in the free software world.
- count 16y ago
  Makes applying security patches a whole bunch of fun too!
  - gregwebs 16y ago
    how is applying patches more difficult? I would think it is normally easier because one can RVM install a new release that has the patches applied.
    - davidw 16y ago
      It's yet another way of installing software on my system. Currently I: * Use apt-get for pretty much everything. * Locally install a few project specific things. These often are installed locally, not system-wide, and have nothing to do with root. * Use rubygems. It's nice, but I don't have the same level of confidence in it regarding security that I do about Debian and Ubuntu. It seems to just give me 'updates' to gems, without much of a way of knowing which updates are security fixes and which are simply improved versions of the packages in question. RVM adds one more thing. And for each Ruby instance in there, I might have various versions of gems floating around. This does not make me happy from a security point of view.
    - mechanical_fish 16y ago
      This might be true, but it does depend on how the release management is done. What else is part of that new release? Is it guaranteed to be a set of minimalist patches to fix security issues, or do the developers also take the opportunity to "tidy up" the API, or take out some of those "deprecated" features, or (god help us) introduce new functionality? [1] Much of what we see here is a dev/ops culture clash. Sysadmins like well-established system-level packaging systems like .deb and .rpm. They like them because they have well-established semantics ("this thing is obviously a security patch; that thing is probably a feature upgrade"), and they like them because these systems abstract away the need for the admin to understand the details of the release model of five or ten or a hundred different open-source ecosystems. Part of OP's complaint is that (from his perspective) the Ruby community has release semantics that he doesn't understand. Is that patch to Ruby 1.8.7 really just a "security fix"? Can it probably be safely applied to 1,000 production servers without causing downtime? --- [1] I should note: I'm not accusing Ruby developers, or any other developers, of ever having done any of these things. But these are the dark thoughts that keep engineers up at night. Especially when managing codebases built on ecosystems that they don't intimately understand.
Vivtek 16y ago
How many other free software projects are significantly hindered by the language used by the main developers? I found that the most fascinating aspect of this post. Software tends to be so very English-centric that the fact that Ruby is Japanese really stands out.
- kscaldef 16y ago
  I believe that early on most of the OCaml community was French-speaking. Personally, I found that aspect of the article borderline offensive. Oh, people shouldn't speak their native language because... speak English dammit! Oh, and don't release software on Dec 25th. (News flash: the majority of the world population does not celebrate Christmas.)
  - moe 16y ago
    Oh, people shouldn't speak their native language because... speak English dammit! Nothing offensive about that, as long as it's expressed in a polite manner. To me it sounds like a constructive proposal from someone who has witnessed the problems first-hand, he's not just "ranting from the sidelines". This is not about imperialism. It's about improving the communications in a project that has long turned international. English is the lowest common denominator. Refusing to acknowledge that simple fact does not help anything.
    - jamtur01 16y ago
      Also given Lucas' native language isn't English either it's hard to claim imperialism.
  - zppx 16y ago
    I think it's a problem when your project goes international. You have to choose a language to communicate with the larger community. Some countries do not have this problem, the Anglo-Saxon world can communicate with a common language, they are inflated by the Indian community that generally uses English in their communication as well. India, with its many official languages, is a living example of how this can be a problem in Science and Technical communities, restricting our problem to programming you'll hardly see an Indian developer starting a project and documenting it in Marathi, Hindi, Urdu, Tamil or Malayalam (or others with more than 10 million speakers). This can be a problem, so you have to decide very early how you'll approach this problem, Linus Torvalds for example chose English in the beginning instead of his native Swedish. The Lua developers chose a similar route, since they native language is Portuguese, I do not know much about Python, but I expect that Guido also chose English to communicate with developers instead of Dutch. Ruby apparently took another way, some people sees this as a problem, others don't, personally I would not like to work in a project in which I cannot ask some guys directly because we do not know a common language to communicate. For me English is a easy choice since the majority of people learn some English in school or college, or even playing games.
crazydiamond 16y ago
RVM has been a boon. 1. Easy to test my library/app against multiple ruby versions. 2. Easy to run an app which requires an older version of ruby (I typically use 1.9.2). Advanced features like gemsets allow finer grained control but only if needed.
- Corrado 16y ago
  RVM is great for some things and a bane for others. Like you, I use it all day, every day to build & test multiple Ruby projects on my MacBook. It has really increased my output and reduced my hair-pulling. On the other hand, automating and managing a server install using RVM is a nightmare. I don't want/need compilers on my servers, I just want to push a package out and have it work (i.e. APT).
  - herval 16y ago
    out of curiosity, what other issues does RVM pose to "others", other than having to apt-get install compilers? also, wouldn't you need compilers anyway, for a whole lot of gems that use native extensions?
    - fhars 16y ago
      No, that is the beauty of using system packages, you just apt-get install them (if they are packaged, that is). That is why it is so important for projects to make it easy for distributions to (re)package extensions.
wccrawford 16y ago
Whoa... Even though the developers of Ruby are Japanese, he's demanding that they start speaking fluent English instead? And he thinks others are being assholes? Granted, he only said 'English' in his rant, but if it's typical Japanese English then he won't understand it half the time anyhow, so it'd have to be fluent English. Here's a novel idea: FORK IT. If you don't like how a project is being run, that's your option. Telling others how to do their work doesn't work with open source. They don't have to listen to you, and calling them assholes certainly doesn't help.
- davidw 16y ago
  You are the one who used the word "asshole", not Lucas, who isn't a native English speaker either.
- gwern 16y ago
  Telling someone to FORK IT is only useful if the maintainers are so incredibly incompetent or toxic that even accepting the massive penalties of a fork (especially massive for huge commercially popular projects) one is better off with the fork. Nowhere else. I don't want to live in a world where this is considered an acceptable response to every small and big criticism or suggestion for improvement: "Hey, maybe we should remove that dead code." "IF YOU DON'T LIKE DEAD CODE, FORK IT!" "Have we considered moving to Git from our crufty old CVS?" "IF YOU DON'T LIKE CVS UP, FORK IT!" "Docbook really isn't very easy to contribute doc fixes to; I was thinking about rewriting our manual in Markdown since it's really not that complex a document - " "FORK IT!"
  - dudus 16y ago
    It's very true. And if you decide to fork it than that's what you hear: "OMG, YOU CAN'T FORK RUBY. ARE YOU CRAZY? THAT WOULD BE TERRIBLE."
    - jamesbritt 16y ago
      It's very true. And if you decide to fork it than that's what you hear: "OMG, YOU CAN'T FORK RUBY. ARE YOU CRAZY? THAT WOULD BE TERRIBLE." Or not: http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-...
hgiug 16y ago
------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec --------
deleted 16y ago
[deleted]
Corrado 16y ago
I really hate to see Lucas burn out and I think the Ruby & Debian communities will both be negatively affected. I'm a Debian Ruby user whose contributed a tiny bit (first Redmine package) and I have watched Lucas and the rest of the team repeatedly bang their heads into a wall when trying to get agreement on something from either side. My personal view is that the Ruby/GEM packages should be laid out like the Perl/CPAN, which seems to be doing just fine. If you want to help, go to the Debian Ruby Team page (http://wiki.debian.org/Teams/Ruby http://wiki.debian.org/Teams/Ruby) and join us (http://wiki.debian.org/Teams/Ruby/RubyExtras/JoiningTheTeam http://wiki.debian.org/Teams/Ruby/RubyExtras/JoiningTheTeam).
- telemachos 16y ago
  > My personal view is that the Ruby/GEM packages should be laid out like the Perl/CPAN, which seems to be doing just fine. Could you say a bit more about what this would look like and how Debian's treatment of Perl differs from how it handles Ruby?
- runjake 16y ago
  I love Perl, and I'm a Perl god. But CPAN is a plague unto it. If any piece of software should be called a ghetto, CPAN is it.
  - telemachos 16y ago
    I like cpanm[1] quite a lot. Have you tried it as an alternative installer for modules? (I'm no Perl god, but I still maintain a healthy chunk of Perl code I wrote for sysadmin things a few years ago. I find that cpanm does exactly what I need it to, without the overhead of CPAN.) [1] https://github.com/miyagawa/cpanminus https://github.com/miyagawa/cpanminus
  - sigzero 16y ago
    I love Perl too. I couldn't disagree more. I love the CPAN and I have had no trouble with it at all.
rb2k_ 16y ago
I just know that whenever I wanted to use the official ubuntu repository, I ended up not being able to install a gem because rubygems was too old. Since gem update --system doesn't seem to work on debian-based systems, I just had to install it from source again
- xiaomai 16y ago
  This wasn't a problem for a long time, but then a major release of release of rubygems came out, and then the switch to gemcutter happened, etc. I've gotten around this by installing everything but rubygems from the regular Ruby packages from the Debian (or ubuntu) repos. I install the rubygems.org version of rubygems and everything works great.
netghost 16y ago
So what is it that RubyGems does differently than other languages that makes it so hard to support? Having a binary debian package for each ruby distro makes sense (as an alternative to rvm), but I'm not really sure why gem is a hindrance.
- telemachos 16y ago
  The Rubygems package can be updated itself (normally) via `gem update --system`. On Debian (and Debian-derived distros), this feature is disabled. I believe their reasoning is that they don't want a package installed and tracked via APT to be updateable outside of APT control and tracking.
  - kscaldef 16y ago
    CPAN can also self-update. So, why is Rubygems bad and CPAN presumably okay?
    - telemachos 16y ago
      I wondered about this myself as I wrote, but I wasn't 100% sure that CPAN could self-update. I don't honestly know why they're treated differently. (I also wonder about cabal and pip and luarocks, etc. I just don't know.) Corrado mentions here that he would like to see Ruby/gems handled more like Perl/CPAN in Debian, but I'm not sure exactly what that means or what it would look like.
      - kposehn 16y ago
        I read through all the comments to make sure no one else has responded. I'm more of a Perl developer then a Ruby developer, but these are my observations of the differences between the two. 1. Perl Versioning is more thought out. It tends to have more consistent versioning semantics. Experimental branches are done in odd minor versions. e.g. 5.11.x was the development version; where 5.12.x is the stable release. All further development occurs on 5.13.x, etc. Patch level changes on the stable version are for minor updates (that don't break compatibility) or security fixes. Major changes to the language that break things are enabled by explicate pragams. E.G. use 5.10; Major version numbers represent core changes to the language, and really represent a new language, that may or may not be compatible with the previous language. E.G. Perl 5.X.x V.S. Perl 6.X.x. This adherence to the value of having development and release versions trickles down to the modules themselves. 2. CPAN is both a tool and the Archive. a. As a tool it is great for both developers and package maintainers. i. For developers: * it allow them to install bleeding edge modules. * easily upgrade those modules ii. For maintainers it allows them to: * query the Archive for various meta information (dependences {build, release}, author, license, etc) * download the modules and extract them * allow the creation of build tools (e.g. dh-make-perl,pbuilder) that automate the packaging of the module b. As an Archive, it provides a common place with an agreed upon standard. i. Modules on CPAN can be marked as a Developer release. ii. Modules on CPAN can also be marked as released version. iii. All information in the Archive can be Queried by the CPAN module, that is part of Perl CORE iv. Perl Core, the interpreter and build tools are well defined. v. Core modules are also well defined, and do not change at patch levels. So, package maintainers can easily package perl modules into their os specific packaging system. To make a Debian package on Lenny from CPAN it's as simple as: dh-make-perl --requiredeps --cpan Module::In::CPAN --build If all your dependences are already in the system this will generate a deb for you, if not it will tell you the modules it could not find; so you can build them. Perl modules allow you change where things are installed by respecting the various PREFIX config options. From what I have read here, it seems this is not true of RubyGems. I don't know enough about RubyGems to know if it does the additional things the CPAN tools does. But the main thing is Perl/CPAN works with Debian by following their rules, and making it easy for them to build deb packages.
tptacek 16y ago
Can I be the jerk on this thread to raise my hand and say, "from what I can see, every single thing Debian has done with Ruby, from the way they split Ruby up into separate packages to the mindboggling damage they inflicted on RubyGems, has worked to the detriment of Ruby and provided no discernable benefit to end-users"? For at least a year now, I've simply accepted that Debian's Ruby lives in a parallel bizarro-universe, rm'd any trace of it that intrudes on my own (real) universe, and installed everything from source. I write this not to feel better about myself but to attract the passionate, angry disagreements that will help me better understand the problems this guy was trying to solve, so I can understand how he looks at the world and what his decision means instead of silently hoping that this post means nobody is going to try to integrate Debian and Ruby anymore.
- halostatue 16y ago
  Thank you. As a Ruby package developer, I have to care about MANY platforms, not just Debian. This is why RubyGems was developed, because neither Windows nor Mac OS X have package managers built in. Debian maintainers may despise RubyGems and what it represents, but the RubyGems developers have never been unwilling to take patches that make them better citizens. They have not, however, been interested in neutering fundamental features.
  - bryanlarsen 16y ago
    That argument would make sense if RubyGems was actually useful on OS X or Windows. But every single application targeted at "normal users" on Windows or OSX written in Ruby bundles all dependencies, usually even including Ruby itself. RubyGems needs to REMOVE harmful features, like the ability to install multiple minor versions of the same gem. Developers should be using RVM to get this capability.
    - tptacek 16y ago
      Huh? OS X is my primary development platform, Debian is my primary deployment platform, and on both, I use a ruby from /usr/local/bin, and I type "bundle install" to get my deps working, and everything works fine.
wglb 16y ago
A similar situation exists in Lisp. Most everyone I know downloads the lisp of their choice (SBCL, CCL, Clojure) from the project site and goes forward from there. This seems particularly true of efforts that are cross-platform. In particular, developing for Linux and Mac pretty much makes this the way to go for these two languages.
lusis 16y ago
What would be nice is if RVM allowed a package option for an installed Ruby + gemset. RVM doesn't work for me on my servers because it break idemopotence but I'd love to install RVM on a testbed, type 'rvm package' and get a tarball that I can dump in /opt/ on my production systems.
tenderlove 16y ago
At RubyKaigi, we talked about closing the Japanese list. It's a bad idea because closing the list will not stop conversations from happening in Japanese, it will just move the conversations to IRC. At least, if we have the conversations recorded, there is an opportunity to translate them.
now 16y ago
Has anyone considered that crap like RubyGems, RVM, and Bundler is a symptom of us as rapid (read: careless) developers not being able to manage our code and our releases in an organized and well-ordered manner, not a symptom of poor package management by distributions?
jhealy 16y ago
I understand Lucas' decision, however it leaves some worrying questions about the state of ruby on Debian systems. Despite the rumours, the ruby1.8, ruby1.9 and rubygems packages are are excellent shape thanks to the hard work by Lucas, Diago and Akira. There were consistent fundamental workflow clashes between upstream and the Debian packagers that have made their job exceedingly difficult. These clashes aren't malicious or antagonistic, they're just the meeting of two very different communities with very different priorities. To name a few of the clashes: API changes in minor releases, effective forking of rubygems by copying it into the 1.9 tree, opaque decision making (mostly due to the language barrier), allowing installed programs (ie rubygems) to update themselves and expectations on what is allowed in /usr/bin. I'm not saying either community is necessarily correct on these issues, just that they add up to some pretty big differences for debian-ruby to navigate. I use the Debian packages for ruby1.8, 1.9.2, jruby and rubygems in both my development and production environments. I've found them stable, rapidly updated in response to security issues and predictable. Lucas - thanks for your efforts, they will be missed.
amacater 16y ago
People - you forget that the Debian community is not just random packagers but also developers. Debian packagers try VERY hard indeed to produce a stable system that works out of the box for all of their users - and that includes developers of all sorts with all types of development environment for several common programming languages. As part of that, it's useful to know what's stable and what isn't. Debian tends to track version numbers and look for stable versions for a reason - once released, Debian commits to supporting a release for the lifetime of that release plus one year - roughly three years now. Anything that isn't actually released as stable and thereby fixed will go into testing/unstable - there's nothing to stop you running the latest and greatest at any time, but possibly not on Debian stable. In another life, I have to deal with developers who say to me: just mirror Ruby and Rails for us on the inside of the corporate firewall. There isn't an easy place to start - if you want to build a Ruby infrastructure inside a large company, with software management systems, management suspicion of FLOSS but committed developers - where do you begin to convince people that this is a usable infrastructure? Red Hat support a subset of very common packages and will support these now for up to 10 years. That's your banks, stock exchanges, infrastructure companies: if you want Ruby developers and programmers to make inroads into that sort of environment, then you need sane packaging sense or at least a sense of what's usable. Debian produces a far larger subset for use of the programs out there - and on 13 hardware architectures. As regards the English/Japanese language flaming: Debian has 1000 or so developers and maintainers, spread worldwide - Lucas is a French speaker, originally, but Debian developers speak and use most common human languages - English is a convenience to a truly distributed, international community.

92 points by philf 16y ago

I've never had very good luck using the Ubuntu Ruby packages. The binaries are never linked, and I can't update Rubygems, which means I can't install a lot of gems that I need. Is it tough to use RVM on a production server? Is it easy to get Thin setup and all that?

thmzlt 16y ago

The same thing happened to Gentoo. I talked to the people behind Ruby packages in Gentoo and they wanted to manually create packages for each gem. It is one of the main reasons why I gave up on Gentoo and went back to Arch Linux. I see gems as just snippets of code instead of "real" OS packages. They change a lot, they are application specific, and (most of the time) they are simple.

davidw 16y ago
> I see gems as just snippets of code instead of "real" OS packages. They change a lot, they are application specific, and (most of the time) they are simple. And, like me, if you're using Rails, they are code that is visible to the outside world. That is code that you want to make sure is secure, and is not just some minor detail.

grimen 16y ago

Evolution is key: Survival of the fittest, and RVM is the fittest in my experience.

davidw 16y ago

I started using RVM a little while ago, and... I am not that excited about it (although it is well done and mostly works as advertised). It seems like the direction Ruby is going is to have things like Rails applications that require their own version of Ruby and a whole slew of gems, which also means that if you have a number of applications, you start getting a large amount of duplication? I'm not entirely sure as I'm new to the system, but it adds an extra level of installed stuff that I'm not 100% comfortable with. Edit: as an aside, Zed Shaw's wild attacks and untruthful accusations against Debian were some ugliness that the world could have done without. I hope Lucas finds other places to more productively (and happily) employ his talents in the free software world.

count 16y ago
Makes applying security patches a whole bunch of fun too!
- gregwebs 16y ago
  how is applying patches more difficult? I would think it is normally easier because one can RVM install a new release that has the patches applied.
  - davidw 16y ago
    It's yet another way of installing software on my system. Currently I: * Use apt-get for pretty much everything. * Locally install a few project specific things. These often are installed locally, not system-wide, and have nothing to do with root. * Use rubygems. It's nice, but I don't have the same level of confidence in it regarding security that I do about Debian and Ubuntu. It seems to just give me 'updates' to gems, without much of a way of knowing which updates are security fixes and which are simply improved versions of the packages in question. RVM adds one more thing. And for each Ruby instance in there, I might have various versions of gems floating around. This does not make me happy from a security point of view.
  - mechanical_fish 16y ago
    This might be true, but it does depend on how the release management is done. What else is part of that new release? Is it guaranteed to be a set of minimalist patches to fix security issues, or do the developers also take the opportunity to "tidy up" the API, or take out some of those "deprecated" features, or (god help us) introduce new functionality? [1] Much of what we see here is a dev/ops culture clash. Sysadmins like well-established system-level packaging systems like .deb and .rpm. They like them because they have well-established semantics ("this thing is obviously a security patch; that thing is probably a feature upgrade"), and they like them because these systems abstract away the need for the admin to understand the details of the release model of five or ten or a hundred different open-source ecosystems. Part of OP's complaint is that (from his perspective) the Ruby community has release semantics that he doesn't understand. Is that patch to Ruby 1.8.7 really just a "security fix"? Can it probably be safely applied to 1,000 production servers without causing downtime? --- [1] I should note: I'm not accusing Ruby developers, or any other developers, of ever having done any of these things. But these are the dark thoughts that keep engineers up at night. Especially when managing codebases built on ecosystems that they don't intimately understand.

Vivtek 16y ago

How many other free software projects are significantly hindered by the language used by the main developers? I found that the most fascinating aspect of this post. Software tends to be so very English-centric that the fact that Ruby is Japanese really stands out.

kscaldef 16y ago
I believe that early on most of the OCaml community was French-speaking. Personally, I found that aspect of the article borderline offensive. Oh, people shouldn't speak their native language because... speak English dammit! Oh, and don't release software on Dec 25th. (News flash: the majority of the world population does not celebrate Christmas.)
- moe 16y ago
  Oh, people shouldn't speak their native language because... speak English dammit! Nothing offensive about that, as long as it's expressed in a polite manner. To me it sounds like a constructive proposal from someone who has witnessed the problems first-hand, he's not just "ranting from the sidelines". This is not about imperialism. It's about improving the communications in a project that has long turned international. English is the lowest common denominator. Refusing to acknowledge that simple fact does not help anything.
  - jamtur01 16y ago
    Also given Lucas' native language isn't English either it's hard to claim imperialism.
- zppx 16y ago
  I think it's a problem when your project goes international. You have to choose a language to communicate with the larger community. Some countries do not have this problem, the Anglo-Saxon world can communicate with a common language, they are inflated by the Indian community that generally uses English in their communication as well. India, with its many official languages, is a living example of how this can be a problem in Science and Technical communities, restricting our problem to programming you'll hardly see an Indian developer starting a project and documenting it in Marathi, Hindi, Urdu, Tamil or Malayalam (or others with more than 10 million speakers). This can be a problem, so you have to decide very early how you'll approach this problem, Linus Torvalds for example chose English in the beginning instead of his native Swedish. The Lua developers chose a similar route, since they native language is Portuguese, I do not know much about Python, but I expect that Guido also chose English to communicate with developers instead of Dutch. Ruby apparently took another way, some people sees this as a problem, others don't, personally I would not like to work in a project in which I cannot ask some guys directly because we do not know a common language to communicate. For me English is a easy choice since the majority of people learn some English in school or college, or even playing games.

crazydiamond 16y ago

RVM has been a boon. 1. Easy to test my library/app against multiple ruby versions. 2. Easy to run an app which requires an older version of ruby (I typically use 1.9.2). Advanced features like gemsets allow finer grained control but only if needed.

Corrado 16y ago
RVM is great for some things and a bane for others. Like you, I use it all day, every day to build & test multiple Ruby projects on my MacBook. It has really increased my output and reduced my hair-pulling. On the other hand, automating and managing a server install using RVM is a nightmare. I don't want/need compilers on my servers, I just want to push a package out and have it work (i.e. APT).
- herval 16y ago
  out of curiosity, what other issues does RVM pose to "others", other than having to apt-get install compilers? also, wouldn't you need compilers anyway, for a whole lot of gems that use native extensions?
  - fhars 16y ago
    No, that is the beauty of using system packages, you just apt-get install them (if they are packaged, that is). That is why it is so important for projects to make it easy for distributions to (re)package extensions.

wccrawford 16y ago

Whoa... Even though the developers of Ruby are Japanese, he's demanding that they start speaking fluent English instead? And he thinks others are being assholes? Granted, he only said 'English' in his rant, but if it's typical Japanese English then he won't understand it half the time anyhow, so it'd have to be fluent English. Here's a novel idea: FORK IT. If you don't like how a project is being run, that's your option. Telling others how to do their work doesn't work with open source. They don't have to listen to you, and calling them assholes certainly doesn't help.

davidw 16y ago
You are the one who used the word "asshole", not Lucas, who isn't a native English speaker either.
gwern 16y ago
Telling someone to FORK IT is only useful if the maintainers are so incredibly incompetent or toxic that even accepting the massive penalties of a fork (especially massive for huge commercially popular projects) one is better off with the fork. Nowhere else. I don't want to live in a world where this is considered an acceptable response to every small and big criticism or suggestion for improvement: "Hey, maybe we should remove that dead code." "IF YOU DON'T LIKE DEAD CODE, FORK IT!" "Have we considered moving to Git from our crufty old CVS?" "IF YOU DON'T LIKE CVS UP, FORK IT!" "Docbook really isn't very easy to contribute doc fixes to; I was thinking about rewriting our manual in Markdown since it's really not that complex a document - " "FORK IT!"
- dudus 16y ago
  It's very true. And if you decide to fork it than that's what you hear: "OMG, YOU CAN'T FORK RUBY. ARE YOU CRAZY? THAT WOULD BE TERRIBLE."
  - jamesbritt 16y ago
    It's very true. And if you decide to fork it than that's what you hear: "OMG, YOU CAN'T FORK RUBY. ARE YOU CRAZY? THAT WOULD BE TERRIBLE." Or not: http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-...

hgiug 16y ago

------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec -------- ------- http://simurl.com/voblec http://simurl.com/voblec --------

deleted 16y ago

[deleted]

Corrado 16y ago

I really hate to see Lucas burn out and I think the Ruby & Debian communities will both be negatively affected. I'm a Debian Ruby user whose contributed a tiny bit (first Redmine package) and I have watched Lucas and the rest of the team repeatedly bang their heads into a wall when trying to get agreement on something from either side. My personal view is that the Ruby/GEM packages should be laid out like the Perl/CPAN, which seems to be doing just fine. If you want to help, go to the Debian Ruby Team page (http://wiki.debian.org/Teams/Ruby http://wiki.debian.org/Teams/Ruby) and join us (http://wiki.debian.org/Teams/Ruby/RubyExtras/JoiningTheTeam http://wiki.debian.org/Teams/Ruby/RubyExtras/JoiningTheTeam).

telemachos 16y ago
> My personal view is that the Ruby/GEM packages should be laid out like the Perl/CPAN, which seems to be doing just fine. Could you say a bit more about what this would look like and how Debian's treatment of Perl differs from how it handles Ruby?
runjake 16y ago
I love Perl, and I'm a Perl god. But CPAN is a plague unto it. If any piece of software should be called a ghetto, CPAN is it.
- telemachos 16y ago
  I like cpanm[1] quite a lot. Have you tried it as an alternative installer for modules? (I'm no Perl god, but I still maintain a healthy chunk of Perl code I wrote for sysadmin things a few years ago. I find that cpanm does exactly what I need it to, without the overhead of CPAN.) [1] https://github.com/miyagawa/cpanminus https://github.com/miyagawa/cpanminus
- sigzero 16y ago
  I love Perl too. I couldn't disagree more. I love the CPAN and I have had no trouble with it at all.

rb2k_ 16y ago

I just know that whenever I wanted to use the official ubuntu repository, I ended up not being able to install a gem because rubygems was too old. Since gem update --system doesn't seem to work on debian-based systems, I just had to install it from source again

xiaomai 16y ago
This wasn't a problem for a long time, but then a major release of release of rubygems came out, and then the switch to gemcutter happened, etc. I've gotten around this by installing everything but rubygems from the regular Ruby packages from the Debian (or ubuntu) repos. I install the rubygems.org version of rubygems and everything works great.

netghost 16y ago

So what is it that RubyGems does differently than other languages that makes it so hard to support? Having a binary debian package for each ruby distro makes sense (as an alternative to rvm), but I'm not really sure why gem is a hindrance.

telemachos 16y ago
The Rubygems package can be updated itself (normally) via `gem update --system`. On Debian (and Debian-derived distros), this feature is disabled. I believe their reasoning is that they don't want a package installed and tracked via APT to be updateable outside of APT control and tracking.
- kscaldef 16y ago
  CPAN can also self-update. So, why is Rubygems bad and CPAN presumably okay?
  - telemachos 16y ago
    I wondered about this myself as I wrote, but I wasn't 100% sure that CPAN could self-update. I don't honestly know why they're treated differently. (I also wonder about cabal and pip and luarocks, etc. I just don't know.) Corrado mentions here that he would like to see Ruby/gems handled more like Perl/CPAN in Debian, but I'm not sure exactly what that means or what it would look like.
    - kposehn 16y ago
      I read through all the comments to make sure no one else has responded. I'm more of a Perl developer then a Ruby developer, but these are my observations of the differences between the two. 1. Perl Versioning is more thought out. It tends to have more consistent versioning semantics. Experimental branches are done in odd minor versions. e.g. 5.11.x was the development version; where 5.12.x is the stable release. All further development occurs on 5.13.x, etc. Patch level changes on the stable version are for minor updates (that don't break compatibility) or security fixes. Major changes to the language that break things are enabled by explicate pragams. E.G. use 5.10; Major version numbers represent core changes to the language, and really represent a new language, that may or may not be compatible with the previous language. E.G. Perl 5.X.x V.S. Perl 6.X.x. This adherence to the value of having development and release versions trickles down to the modules themselves. 2. CPAN is both a tool and the Archive. a. As a tool it is great for both developers and package maintainers. i. For developers: * it allow them to install bleeding edge modules. * easily upgrade those modules ii. For maintainers it allows them to: * query the Archive for various meta information (dependences {build, release}, author, license, etc) * download the modules and extract them * allow the creation of build tools (e.g. dh-make-perl,pbuilder) that automate the packaging of the module b. As an Archive, it provides a common place with an agreed upon standard. i. Modules on CPAN can be marked as a Developer release. ii. Modules on CPAN can also be marked as released version. iii. All information in the Archive can be Queried by the CPAN module, that is part of Perl CORE iv. Perl Core, the interpreter and build tools are well defined. v. Core modules are also well defined, and do not change at patch levels. So, package maintainers can easily package perl modules into their os specific packaging system. To make a Debian package on Lenny from CPAN it's as simple as: dh-make-perl --requiredeps --cpan Module::In::CPAN --build If all your dependences are already in the system this will generate a deb for you, if not it will tell you the modules it could not find; so you can build them. Perl modules allow you change where things are installed by respecting the various PREFIX config options. From what I have read here, it seems this is not true of RubyGems. I don't know enough about RubyGems to know if it does the additional things the CPAN tools does. But the main thing is Perl/CPAN works with Debian by following their rules, and making it easy for them to build deb packages.

tptacek 16y ago

Can I be the jerk on this thread to raise my hand and say, "from what I can see, every single thing Debian has done with Ruby, from the way they split Ruby up into separate packages to the mindboggling damage they inflicted on RubyGems, has worked to the detriment of Ruby and provided no discernable benefit to end-users"? For at least a year now, I've simply accepted that Debian's Ruby lives in a parallel bizarro-universe, rm'd any trace of it that intrudes on my own (real) universe, and installed everything from source. I write this not to feel better about myself but to attract the passionate, angry disagreements that will help me better understand the problems this guy was trying to solve, so I can understand how he looks at the world and what his decision means instead of silently hoping that this post means nobody is going to try to integrate Debian and Ruby anymore.

halostatue 16y ago
Thank you. As a Ruby package developer, I have to care about MANY platforms, not just Debian. This is why RubyGems was developed, because neither Windows nor Mac OS X have package managers built in. Debian maintainers may despise RubyGems and what it represents, but the RubyGems developers have never been unwilling to take patches that make them better citizens. They have not, however, been interested in neutering fundamental features.
- bryanlarsen 16y ago
  That argument would make sense if RubyGems was actually useful on OS X or Windows. But every single application targeted at "normal users" on Windows or OSX written in Ruby bundles all dependencies, usually even including Ruby itself. RubyGems needs to REMOVE harmful features, like the ability to install multiple minor versions of the same gem. Developers should be using RVM to get this capability.
  - tptacek 16y ago
    Huh? OS X is my primary development platform, Debian is my primary deployment platform, and on both, I use a ruby from /usr/local/bin, and I type "bundle install" to get my deps working, and everything works fine.

wglb 16y ago

A similar situation exists in Lisp. Most everyone I know downloads the lisp of their choice (SBCL, CCL, Clojure) from the project site and goes forward from there. This seems particularly true of efforts that are cross-platform. In particular, developing for Linux and Mac pretty much makes this the way to go for these two languages.

lusis 16y ago

What would be nice is if RVM allowed a package option for an installed Ruby + gemset. RVM doesn't work for me on my servers because it break idemopotence but I'd love to install RVM on a testbed, type 'rvm package' and get a tarball that I can dump in /opt/ on my production systems.

tenderlove 16y ago

At RubyKaigi, we talked about closing the Japanese list. It's a bad idea because closing the list will not stop conversations from happening in Japanese, it will just move the conversations to IRC. At least, if we have the conversations recorded, there is an opportunity to translate them.

now 16y ago

Has anyone considered that crap like RubyGems, RVM, and Bundler is a symptom of us as rapid (read: careless) developers not being able to manage our code and our releases in an organized and well-ordered manner, not a symptom of poor package management by distributions?

jhealy 16y ago

I understand Lucas' decision, however it leaves some worrying questions about the state of ruby on Debian systems. Despite the rumours, the ruby1.8, ruby1.9 and rubygems packages are are excellent shape thanks to the hard work by Lucas, Diago and Akira. There were consistent fundamental workflow clashes between upstream and the Debian packagers that have made their job exceedingly difficult. These clashes aren't malicious or antagonistic, they're just the meeting of two very different communities with very different priorities. To name a few of the clashes: API changes in minor releases, effective forking of rubygems by copying it into the 1.9 tree, opaque decision making (mostly due to the language barrier), allowing installed programs (ie rubygems) to update themselves and expectations on what is allowed in /usr/bin. I'm not saying either community is necessarily correct on these issues, just that they add up to some pretty big differences for debian-ruby to navigate. I use the Debian packages for ruby1.8, 1.9.2, jruby and rubygems in both my development and production environments. I've found them stable, rapidly updated in response to security issues and predictable. Lucas - thanks for your efforts, they will be missed.

amacater 16y ago

People - you forget that the Debian community is not just random packagers but also developers. Debian packagers try VERY hard indeed to produce a stable system that works out of the box for all of their users - and that includes developers of all sorts with all types of development environment for several common programming languages. As part of that, it's useful to know what's stable and what isn't. Debian tends to track version numbers and look for stable versions for a reason - once released, Debian commits to supporting a release for the lifetime of that release plus one year - roughly three years now. Anything that isn't actually released as stable and thereby fixed will go into testing/unstable - there's nothing to stop you running the latest and greatest at any time, but possibly not on Debian stable. In another life, I have to deal with developers who say to me: just mirror Ruby and Rails for us on the inside of the corporate firewall. There isn't an easy place to start - if you want to build a Ruby infrastructure inside a large company, with software management systems, management suspicion of FLOSS but committed developers - where do you begin to convince people that this is a usable infrastructure? Red Hat support a subset of very common packages and will support these now for up to 10 years. That's your banks, stock exchanges, infrastructure companies: if you want Ruby developers and programmers to make inroads into that sort of environment, then you need sane packaging sense or at least a sense of what's usable. Debian produces a far larger subset for use of the programs out there - and on 13 hardware architectures. As regards the English/Japanese language flaming: Debian has 1000 or so developers and maintainers, spread worldwide - Lucas is a French speaker, originally, but Debian developers speak and use most common human languages - English is a convenience to a truly distributed, international community.