Comments on: Why I hate Rubygems http://hcoder.org/2008/11/23/why-i-hate-rubygems/ Just another WordPress weblog Thu, 29 Jul 2010 02:46:07 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Sverre Johansen http://hcoder.org/2008/11/23/why-i-hate-rubygems/comment-page-1/#comment-191 Sverre Johansen Thu, 01 Jan 1970 00:00:00 +0000 I like to have a separate development environment, and install the language specific packages within this virtual environment, separate from the rest of the system. For my current Python projects I do this with either Virtualenv or zc.buildout. Then I get the latest and greatest from the community, and at the same time I don't interfere with the rest of the system. Another alternative is to create platform specific packages for each of the dependency, but that is extra work that I would love being without. This also ties the project to one specific OS, which might be OK for internal software, but you will have to do all the packaging again for another OS. My current project uses the same packages for Gentoo, Debian, Ubuntu, OSX and Windows. I like to have a separate development environment, and install the language specific packages within this virtual environment, separate from the rest of the system.

For my current Python projects I do this with either Virtualenv or zc.buildout. Then I get the latest and greatest from the community, and at the same time I don’t interfere with the rest of the system.

Another alternative is to create platform specific packages for each of the dependency, but that is extra work that I would love being without. This also ties the project to one specific OS, which might be OK for internal software, but you will have to do all the packaging again for another OS.

My current project uses the same packages for Gentoo, Debian, Ubuntu, OSX and Windows.

]]> By: Esteban http://hcoder.org/2008/11/23/why-i-hate-rubygems/comment-page-1/#comment-192 Esteban Thu, 01 Jan 1970 00:00:00 +0000 Well, for me separate environments are chroots or some other virtual machine, were you can install whatever collection of packages you want. After all, your environment is not only the modules for a certain language, but the whole system. Of course it's somewhat harder to setup or maintain, but if you want a real separate environment, I think that's the way to go. Having the latest and greatest, although regarded as obviously good by every measure by the Python and Ruby communities (apparently), I think is not necessarily that good, at least when the updates are "not controlled", and you don't have an easy/default way to stick to certain known-to-work versions. What I mean is that installing directly using gems or easy_install (or CPAN for that matter) gives you, by default, the latest version of every package that is installed. And the problem I see is that the "latest version" is something that changes over time, so there's no easy way to be sure that you're using the same versions in all your servers (unless you upgrade all servers every day, but that's nuts). And by "all" here I don't mean just the production servers, I mean the whole chain. Of course, if you're writing some software that you have to deploy in multiple systems, probably the only sane way to achieve it is using Rubygems/easy_install/CPAN or similar, as you point out. But that's not my case or the case I'm the most interested in, and for "generic" software (as in Open Source and such) I think the best solution is separating the roles of "upstream" and packagers and allowing each system community to maintain packages of your software, tailored and adapted to their system. Well, for me separate environments are chroots or some other virtual machine, were you can install whatever collection of packages you want. After all, your environment is not only the modules for a certain language, but the whole system. Of course it’s somewhat harder to setup or maintain, but if you want a real separate environment, I think that’s the way to go.

Having the latest and greatest, although regarded as obviously good by every measure by the Python and Ruby communities (apparently), I think is not necessarily that good, at least when the updates are “not controlled”, and you don’t have an easy/default way to stick to certain known-to-work versions. What I mean is that installing directly using gems or easy_install (or CPAN for that matter) gives you, by default, the latest version of every package that is installed. And the problem I see is that the “latest version” is something that changes over time, so there’s no easy way to be sure that you’re using the same versions in all your servers (unless you upgrade all servers every day, but that’s nuts). And by “all” here I don’t mean just the production servers, I mean the whole chain.

Of course, if you’re writing some software that you have to deploy in multiple systems, probably the only sane way to achieve it is using Rubygems/easy_install/CPAN or similar, as you point out. But that’s not my case or the case I’m the most interested in, and for “generic” software (as in Open Source and such) I think the best solution is separating the roles of “upstream” and packagers and allowing each system community to maintain packages of your software, tailored and adapted to their system.

]]> By: Esteban http://hcoder.org/2008/11/23/why-i-hate-rubygems/comment-page-1/#comment-193 Esteban Thu, 01 Jan 1970 00:00:00 +0000 Oh, and BTW. I think the main reason why I feel Rubygems suck is because they're *hard* to repackage. I don't mind so much that people *use* Rubygems themselves, but I hate that people are distributing their software using a hard-to-repackage format instead of using something like, for example, CPAN. Oh, and BTW. I think the main reason why I feel Rubygems suck is because they’re *hard* to repackage. I don’t mind so much that people *use* Rubygems themselves, but I hate that people are distributing their software using a hard-to-repackage format instead of using something like, for example, CPAN.

]]>