I have always thought that systems should be something integrated. Each “system” has its own conventions, cultural values, etc. and I think you have to respect that. I believe in the Debian way (adapting programs to an integrated system, not just creating a large collection of packages that are identical to the upstream versions), I like to adapt my style of programming to the language (indentation conventions, identifiers, tools for building and testing, etc.), I prefer cross-platform applications that look and feel like each platform they run on, etc.
In the same way, I feel that the mere idea of having a programming-language-dependent packaging system is a broken idea. I know it has advantages, and I know that being specific to the language, some things work better or are more flexible, but I just don’t believe in that idea. Why should I use a different packaging system for certain things just because they’re written in Ruby? Why do I, as a user of those programs/modules, even have to know that there’s some Ruby-specific packaging system, that doesn’t integrate at all with my system’s packaging system, and mixing both leads to a mess?
Not only that, but Rubygems in particular is quite hostile to repackaging into a platform-specific packaging system. A lot of people only provide the gems for their software, which are harder to work with than “normal” tarballs. They also use their own conventions for directories, that break the FHS (for example) and basically only make sense in the context of Rubygems. In that sense, CPAN is much better (although I think using it for application deployment is a very bad idea, but that’s a different matter), because at least it installs everything in sane directories, it doesn’t change Perl in any way, and it’s not a special format, just a repository of easy-to-install, easy-to-work-with, easy-to-hack, easy-to-repackage “distributions”.
Why, oh, why?
Posts
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.
November 26, 2008 @ 1:59 pm
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.
November 27, 2008 @ 7:03 pm
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.
November 27, 2008 @ 7:06 pm