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

[Christopher Allan Webber]

Dave Crossland writes:

> On 8 April 2015 at 11:22, Christopher Allan Webber <address@hidden>
> wrote:
>
>>
>>  - Language packaging for deployment needs to die.  Yes, I say this as a
>>    project that advocates that very route.  We're doing it wrong, and
>>    I want to change it.
>>    (Language packaging for development though: that's great!)
>>
> I think this is what set me off ranting about your gestalt thinking :)
>
> If language packaging sucks for deployment, it sucks for development.

That's probably true.

Here's a story to back up your point: I recently wanted to get away from
the oh-too-common antipattern of "check your javascript into your git
repo" (yuck) which MediaGoblin does because, let's face it, a few years
ago that's what *all* developers did, and so now we're tearing it out
and we need an easy way for developers to get those css and javascript
and etc files in place, and how to do it?  I tried to think up a
solution, but rightly the community pointed out that my solution started
to look like inventing a new package manager, and not to do that.

So what did we do?  We added bower, which itself depends on npm.

So now we have *three* "language package managers" (though npm and bower
kind of come together).  That sucks, especially because when something
goes bad on a language package manager, it seems like you need a
language expert to help dig you out of that mess.

On the upside one reason for doing this is to make it so that we have an
easier story for packagers, where anything currently using bower for
development should be a package installed with yum or apt-get or
whatever, but still...

> Language packaging is abstracting the operating system, so the installation
> of a local package is the same on win/gnu/osx/illumos when these systems
> are running on bare metal.
>
> Now containers are here, it's an inappropriate level of abstraction,
> because developers need to deploy their overall systems, which are often
> composed of programs in various languages.
>
> This leads to, as Dave Thompson just said, using a set of language
> packaging systems.
>
> This is just about bearable when just installing individual packages on
> your special snowflake metal, typically the one by your legs with a cute
> hostname.
>
> But if your computers have a personal hostname instead of an impersonal
> one, that's another tell of deprecated pre-container thinking.

On the "functional package management" side, this has also come up with
Guix, which can already do something along the lines of a "universal
virtualenv", as long as you have Guix installed.  (Guix will hopefully
be able to do containerization soon too, so you should be able to spin
up containers on the fly for development... you already can for VMs,
iirc.  Feel free to weigh in, Dave!)

> Containers are about eliminating all the on disk differences between
> development, CI, qa, and operational deployment.
>
> It should be whales all the way down.
> Then moving server to server is easy, because it's a common (several times
> a day) thing you do. If you can't do it that frequently and rapidly, it's
> not easy enough.

BTW, I think there's an impression that I'm anti-container on this
thread, and I'm not, but I will reply elsewhere on the thread clarifying.