3 ms·
Where I like to draw the line between apt and rubygems/pip is between "things that are base system" and "things that are app deployment". So in a typical rails
by pedrocr 13y ago
Where I like to draw the line between apt and rubygems/pip is between "things that are base system" and "things that are app deployment". So in a typical rails stack that would be apt installs the system-wide stack (apache, ruby, passenger, rubygems) and then capistrano is used to deploy my webapps with their gems from my dev machine to their app-specific directory in the production server.
This way I can have my sysadmin hat on while setting up the server and depend on debian/ubuntu to handle security upgrades and generally create a consistent system. Then I can put my devops hat on and use capistrano and bundler to manage the security/dependencies of my own code.
But I see where this breaks down. If the base stack is moving at a much faster pace than the distributions (e.g., right now the version of passenger in Ubuntu LTS is incredibly old) it's attractive to just ignore the system packages and install everything from original sources (e.g., install ruby from source with rbenv). But doing that is just throwing away the integration work the distribution has done. I'd much rather include some extra repositories to get updated versions that integrate through apt for the few things that I care to upgrade faster than Ubuntu LTS allows me. Right now that's puppet, passenger and a few more.
- rlpb 13y agoI agree with you. The pain occurs when this breaks down. Take Vagrant, for example. Brilliant tool. Depends on gems that weren't distro packaged for years. This made Vagrant unusable for anyone not deploying a ruby-based application stack, unless sysadmins accepted that they were going to have to deal with the extra work associated with multiple vendors and update mechanisms for each language on the system. So those of us using other stacks could use Vagrant, but only if we adopted Ruby's app-level packaging system. See https://news.ycombinator.com/item?id=2059964 https://news.ycombinator.com/item?id=2059964 as an example of life being made difficult for distro packagers by the Ruby community. Since Rubyists tend to insist that distro packages are bad, so this is how it tends to stay. Thankfully the packaging of Vagrant and dependencies has now happened (finally; after years), and I can "apt-get install vagrant" now. But I hope this illustrates the problem. In the common use case, there is a dichotomy between distro and app-level dependencies, packaging and development. But in the grand scheme of things we all want to share our work across communities, and this dichotomy is a barrier to this ideal. Dependencies don't just go in one direction with language module repositories like pypi and rubygems at the top. Sometimes we want parts of the system to depend on them, too.
- pedrocr 13y agoI think the issue is one of development speed. Currently things like passenger and puppet are behind on Ubuntu LTS packaging because their development cycle is much faster than LTS releases. Apache on the other hand is well past that point, while nginx is probably somewhere in between. Right now I install passenger through gems but I'll be moving that to the just released deb repository the phusion guys have just released and eventually I expect development to quiet down enough that Ubuntu's packaging will be up to date enough. So basically I expect software packaging to evolve in three steps: 1. When in fast development get it from gems (my case with passenger now) 2. When it starts getting mature (or as soon as you have resources to do enough QA) build a deb repository (puppetlabs does this for puppet) 3. When it becomes stable and boring just use what's in the system (apache and thousands of other things) Moving from step 1 to 2 is probably not natural for a lot of ruby (and python to a lesser extent) developers because they see their software in the context of apps that are "things you deploy to a host" not "things that are part of the base system".