mediagoblin-userops
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Userops] Why is it hard to move from one machine to another? An ana


From: Dave Thompson
Subject: Re: [Userops] Why is it hard to move from one machine to another? An analysis.
Date: Thu, 09 Apr 2015 11:25:35 -0400
User-agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)

"Claes Wallin (韋嘉誠)" <address@hidden> writes:

> Because services are not run as several instances by several users on
> one machine, their state has been allowed to nestle itself into
> several places on the system.
>
> This is why bundler/npm/virtualenv is often the best way to deploy,
> because it isolates the application state (and dependencies) from the
> system (and other installed services). Docker looked like it could be
> a polyglot version of this, but I guess from what you are saying
> people are not using it like that.

I think there are much better ways that we can isolate application
dependencies.  Bundler and co. are useful only because system package
managers haven't traditionally allowed for installing to a directory
that isn't '/'.  Language-specific package managers let you install
anywhere, but they are so narrow in scope that you typically need to use
more than one of them in addition to your distro's package manager to
get any real work done.  So, a Ruby on Rails application with a
JavaScript client may need apt, npm, and bundler in order to obtain all
of the pieces necessary for it to work.  Terrible.  The distros we use
should provide a package manager that allow us to do this kind of
dependency isolation with all packages, not just Ruby/Python/JavaScript
stuff, while at the same de-duplicating the files used in multiple
"bundles" throughout the system.  Then we'd only need one package
manager.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate


reply via email to

[Prev in Thread] Current Thread [Next in Thread]