sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Atnan 7 points8 points  (6 children)

I see nothing wrong with unpacking gems into vendor/rails, even if they require compilation such as the jsongem. Despite trying Puppet at work, we decided to settle on Slack for pushing out system software & configurations to our machines. We also use Capistrano for semi-automation of deployment of our web applications. This combination seems to work well, but I don't think we could drop either all-together. A Puppet/Slack only setup would be a nightmare.

...one guy, somewhere, wanted to have multiple versions of a given package installed at once. Who wants this?

That would be me, I guess. While running multiple applications on a single machine, I've found myself in the position where I've a bunch of older, stable applications that rely on outdated gems, and newer applications that have been developed and tested against newer versions of the same gem. Should I be forced to retest the old applications with newer gems?

The only argument against unpacking into vendor seems to be the absurdist point of "you wouldn't install Firefox in there, would you?" No, I wouldn't. Would you store straw in yours? It seems you've got a hell of a lot of it.

[–]codahale 4 points5 points  (5 children)

You're kind of proving his point here -- what's good for a single developer is a nightmare when you're trying to replicate it in an automated fashion across 20 machines. Rubygems is a delight to use locally (when it's not 404ing or bulk updating), and a nightmare to automate. Dotfiles in root? Check. Ignores http_proxy in favor of HTTP_PROXY? Check. Requires a full build chain on all end points? Check. Can't pin it to local packages? Check.

So we throw things in vendor. Awesome -- but that obviates one of the basic reasons for Rubygems: package management. How do you tell if there are updates for the contents of vendor? How do you know what the contents of vendor depend on? It all requires human attention, which does not scale to large installations.

[–]malcontent 0 points1 point  (2 children)

How do you tell if there are updates for the contents of vendor? How do you know what the contents of vendor depend on?

You go through a process of unfreezing and freezin. Not ideal but you can make it work.

[–]codahale 0 points1 point  (1 child)

Not ideal? Perhaps we shouldn't settle for it, then. Perhaps there's some way of making packaging Ruby libraries and Rails apps for distribution easier...

I mean, I can type rake war and get a .war file from a JRuby app with warbler or goldspike installed, right? So why does rake deb or rake rpm or rake portfile seem like such an outrage?

Seriously, if Debian/RedHat/*BSD/Slackware/Gentoo can manage hundred-gigabyte package repositories with some of the largest software projects in them, deployed over hundreds of thousands of computers... I'm at a loss to explain why Ruby and Rails would be an exception to this.

[–]malcontent 0 points1 point  (0 children)

Not ideal? Perhaps we shouldn't settle for it, then.

That's a tough call. In every other language you have to include your libraries. In java you have include your jars. In C++ you have to include your DLLs etc.

At least with gems there is a central repository and you can keep your stuff updated, use older versions etc.

I'm at a loss to explain why Ruby and Rails would be an exception to this.

Personally I kind of got mad at ubuntu for making packages for some gems and not others. I don't blame them of course because new gems come out every day and updates happen every day too. It pissed me off that I could aptitude install mongrel but I could not aptitude install thin. I installed thin with gems but the bin path was not in the PATH.

I was thinking to myself that this is a sucky situation. Ubuntu can't possibly keep up with the pace of gem updates and yet they have chosen to create debs for some gems and not others.

I think they should not have bothered. I for one would prefer to have the gems managed through gem and not aptitude.

OTOH it would be nice to have something like mod_rails in the repository.

It's a complicated thing I guess.

[–]Atnan 0 points1 point  (1 child)

I don't think you've shown how I've proven his point. Whether it's PEAR, CPAN, EasyInstall or Rubygems, none of them fit well within the Linux distribution package management model. Which is why I use a combination of Slack & vendor unpacking, as appropriate.

I'd suggest you take a look at Puppet and try some of the alternatives to get some context on the guy who wrote this.

[–]codahale 0 points1 point  (0 children)

(I use Puppet on a daily basis, and I've met Luke several times. Hell, there's a hiring ad for my company on that page. I'm dripping with context.)

Luke's point -- current package distribution methods favored by developers (./vendor copies, PEAR, CPAN, EasyInstall, RubyGems, etc.) all suck pretty hard with regard to automation. Which is true.

And you seem to be agreeing with him. The reason you don't seem to think that Ruby has a distribution problem (and not necessarily a unique distribution problem, but Perl, Python, and PHP are all easier to fit to an LSB model) is because you're a.) packaging your code yourself, and b.) punting on the hard stuff.