It is definitely not a coincidence that whenever I have to dive into Gentoo Ruby packaging I end up writing a long series of articles for my blog that should have the tag “Rant” attached, until I end up deciding that it’s not worth it and I should rather do something else.
The problem is that, as I said many times before (and I guess the Debian Ruby team agrees as well), the whole design of RubyGems makes it very difficult to package them properly, and at the same time provides the developers with enough concepts to make the packaging even more tricky than it would by merely due tot he format.
As the title says, for one reason or another, RubyGems’s main accomplishment is simply to put extensions’ developers and distributions’ packages one against the other, with the former group insisting on doing things “fun”, and the latter doing things “right’. I guess most of the members of the former group also never tried managing a long term deployment of their application outside of things like Heroku (that are paid to take care of that).
And before somebody tells me I’m being mean by painting the developers puny with their concept of fun, it’s not my fault if in the space of an hour after tweeting a shorter version of the first paragraph of this post, two people told me that “development is fun”… I’m afraid for most people that’s what matters, it being fun, not reliable or solid…
At any rate… even though as we speak nobody expressed interest (via flattr) on packaging of the Ruby MongoDB driver that I posted about yesterday, I started looking into it (mostly because I’m doing another computer recovery for a customer and thus I had some free time in my hands while I waited for antivirus to complete, dd_rescue to copy data over, and so on so forth).
I was able to get some basic gems for bson and mongo working, which were part of the hydra repository I noted, but the problems started when I looked into plucky which is the “thin layer” used by the actual ORM. It is not surprising that this gem also is “neutered” to the point of being useless for Gentoo packaging requirements, but there are more issues. First of all it required one more totally new gem to be packaged – log_buddy which also required some fixes – that is not listed in the RubyGems website (which is proper, if you consider that the tests are not executable from the gem file), but most importantly, it relied on the matchy gem.
This is something I already had to deal with, as it was in another long list of dependencies last year or the one before (I honestly forgot). This gem is interesting: while the package is dev-ruby/matchy, it was only available as a person-specific gem in Gemcutter: jnunemaker-matchy and mcmire-matchy; the former is the original (0.4.0), while the latter is a fork that fixed a few issues, among which there was the main problem: jnunemaker-matchy is available neither as a tarball nor as a git tag.
For the package that originally required matchy for us (dev-ruby/crack), mcmire’s fork worked quite well, and indeed it was just a matter of telling it to use the other gem for it to work. That’s not the case for plucky, even thought jnunemaker didn’t release any version of matchy in two years, it only works with his version of matchy. Which meant packaging that one as well, for now.
Did I tell you that mcmire’s version works with Ruby 1.9, while jnunemaker’s doesn’t? No? Well, I’m telling you now. Just so you know, almost in 2012, this is a big deal.
And no, there is not a 0.4.0 yet. Two years after release. The code stagnated since then.
Oh and plucky’s tests will fail depending on how Ruby decides to sort an Hash’s keys array. Array comparison in Ruby is (obviously) ordered.
Then you look at the actual mongo_mapper gem that was the leaf of the whole tree.. and you find out that running the tests without bundler fixing the dependencies is actually impossible (due to the three versions of i18n that we have to allow side-installation of). And the Gemfile, while never declaring dependencies on the official Mongo driver (it gets it through plucky), looks for bson_ext (the compiled C extension, that in Gentoo was not going to exist, since it’s actually installed by the same bson package — I’ll have to create a fake gemspec for it just so it can be satisfied).
And this actually brings us to a different problem as well: even though plucky has been updated (to version 0.4.3) in November, it still requires series 1.3 of the Mongo driver. Version 1.4.0 was released in September, and we’re at version 1.5.2.
And I didn’t name SystemTimer gem, which is declared a requirement during development (but not by the gem of course, since you’re not supposed to run tests there) only for Ruby 1.8 (actually only for mri18, what about Ruby EE?) which lacks an indication of a homepage in the RubyGems website….
I love Ruby. I hate its development.
Thought this might cheer you uphttp://www.youtube.com/watc…
Ruby development has been invaded by hipsters who care about stuff being cool, not being reliable. They care to the point it seems to work on their Macbooks and that’s it.It’s no surprise that by going with MongoDB (used mostly by hipsters who don’t actually need it) you are having these issues.I’d rather use something with less followers on GitHub but that actually has versions, centralized release management (actually, just some kind of release management would be better), proper documentation, and actually works.
Having any suggestion ready? I mean MongoDB looked like the best of the “nosql” folks (and I hate such a term because my problem is definitely _not_ with SQL, but with the fact I have data that, to make relational, would require more massaging than it’s worth spending time on).In particular, at least MongoDB is not saying that you have to forget all about indexes… which instead seem to be what CouchDB and others’ documentation states :/But otherwise you’re right… so if you have suggestion of any other document-based “database”, I’d be thrilled to hear it.
Would recutils from GNU suit your needs?
Sure, does it allow indexing and has an ActiveModel backend? 😉
I wouldn’t like tell you why other distributions does not repackage rubygems. Gems already have package manager, ‘gem’, and usually the Ruby developers are satisfied with it.I don’t say it is good, or an idea what anybody can follow, this is just a reality. The Ruby (exactly: gem) developers are not interested in repackaging their stuffz.
The @gem@ package manager is a _joke_.The gems are not tested, their dependencies are rarely correct, and a number of time, as trololol said, “it works on their macbooks so it’s a gem”.And it’s not true that other distributions do not package gems; Debian does, and has had most of our own issues as well. Developers who do care about their code are probably thanking us for going through this, as we often enough find issues that would otherwise go unseen..If developers are not interested.. then I’d seriously think that they should stop _releasing_ their stuff, it’ll be better for everyone.
I usually do not use distibution’s package manager for gems, because it is rarely correct solution. However, in my experience, @gem@ is always work as I expect it. You are partially right, because @gem@ is not have an ‘or’ logical operation in dependencies, so it depends on developer’s decision which alternative choosen, or the choose is given to the user. But these gems are very rare, and I do not think there are too many.I am on that party where the @gem@ is a right solution, because distribution packages are old, unstable, unusable, and distribution package manager does not supports the @gem@ manager. I sucked a long time with Debian/Ubuntu gem repackaging, and on a user side, that is a horror, trust me.
From system administrator’s point of view anything that’s not controlled by the main package manager is a liability and maintenance nightmare waiting to start probably around Friday noon or worse.
We need to move away from this universe of different, incompatible package managers and associated formats.Right now we have silos for programming languages and more silos for operating systems. This is dumb. A software package published on the web isn’t necessarily (and shouldn’t be) targeted at a single operating system or programming language community.There is a lot of agreement in a lot of other areas in computing. We have POSIX, Unicode, URIs (now IRIs), etc.We should be able to put these things together to arrive at a set of packaging-related metadata that any software library or application can include in its source and binary distributions.
Charlie: Package Kit?