Hashemi: The Many Layers of Packaging

Posted May 13, 2017 16:45 UTC (Sat) by drag (guest, #31333)
In reply to: Hashemi: The Many Layers of Packaging by callegar
Parent article: Hashemi: The Many Layers of Packaging

I use pyenv, which is modeled after the rbenv tool. To deal with these issues for development purposes.

There exists *env work-alikes for other languages. I started using plenv for perl just recently and from my limited experience it's pretty effective. It would be lovely to see this standardized.

The root cause of the 'fragility' of things like virtualenv is depending on distro-packaged and OS-level software. You can't depend on OS software environments and distro-packaged software if you want to have something that easy to develop on and want to have both testable and recreate-able. If you want to be able to test and support different versions of multiple Linux distributions then depending on OS packaging is a terrible idea.

Using 'naked' virtualenv/venv is essentially half-assing it. So you end up with worst of both worlds were you have to go through the trouble of setting up a venv, keeping track of dependencies and such things on your own, and then depending on OS provided basic libraries and interpreters that update and break things based on their own convenience and time-lines and not your own.

So pyenv is a simple way to manage your own dev environment and divorce it from the OS-level dependencies as much as is currently easily possible. You can set (depending on the shell your using) directory-specific interpreters, shell-session specific interpreters, global default interpreters. You can integrate with things like Emacs so it's aware of your interpreter paths and libs and whatnot so you don't depend on system-version of python for things like lint.

It's not 100% as you still run into some issues with distro-specific dependencies that are used to build the interpreter, like SSL libs. The work around is to use pyenv on the older distributions to recreate the application dev environment you are using on your desktop. So I can do things like develop on Fedora 25 using my native editor and latest python version and still have very little issues targeting Centos 6... Going back to CentOS 5 is a bit more trouble, but it's actually do-able.

Unfortunately you can't expect end users to go through all the work of setting up pyenv.

The holy grail for easy distribution right now is static binaries. You have your user's wget the binary or very simple tarball and it's done. For security you provide a signature file for the download or signed sha256sum file and upload your gpg key to a public key server. The downside of not depending on OS for security updates is offset by the fact that you can rapidly get new binaries built, signed and uploaded and users don't have to do anything more then just re-download them. If a user runs into some sort of breakage with a update usually the 'roll back' is just using the old binary they have copied to a backup dir.

Lack of automation to check signatures and updates is it's real weakness versus distro-specific packaging. Also python is not designed for building static libraries so it's always going to have niggling issues when you try to do it. I've done it with success and had binaries that ran just fine on everything from CentOS 5 to latest Fedora, but it's not simple and you can't use whatever libs you want.

With the success of golang it really is pointing that this sort of thing is the way to go forward. Maybe containers can be made nice enough to solve the issue of repeatable application environments divorced from distribution-specific dependencies with automated signature checking and updates.

Hashemi: The Many Layers of Packaging

Posted May 13, 2017 20:18 UTC (Sat) by lsl (subscriber, #86508) [Link] (1 responses)

> depending on OS provided basic libraries and interpreters that update and break things based on their own convenience and time-lines and not your own.

You might be able to control everything for purely internal programs but if your software has any external users, that's what it's going to get exposed to in production anyway. Users are going to setup their systems as they feel like and won't feel guilty about not having asked for your permission beforehand. And as long as that setup is not totally crazy...why not support it, at least on a best-effort basis?

For most sane libraries that have existed for a long time and provide well-engineered APIs, relying on the OS version seems like the obvious choice. For the more unstable and experimental stuff, yeah, just link it statically.

> Lack of automation to check signatures and updates is it's real weakness versus distro-specific packaging.

Why not drop those static binaries into an RPM or Debian package then? Those won't go into the distro repos but you still get to benefit from the updating and signature checking infrastructure built into those systems.

Hashemi: The Many Layers of Packaging

Posted May 13, 2017 23:57 UTC (Sat) by drag (guest, #31333) [Link]

> For most sane libraries that have existed for a long time and provide well-engineered APIs, relying on the OS version seems like the obvious choice.

Sometimes. C libraries are tricky. However the main point is dealing with python modules themselves. When they depend on C/C++ libraries you have to make special considerations. The most troublesome tend to be things like OpenSSL. It requires distro-specific testing if you don't want to get burned by surprise incompatibilities. Since Python is designed for building dynamic things then it's difficult to create truly 'static' binaries.

Golang really wins in this regard. You can do stuff like setup a 'docker image' that consists of a single binary with some config data for a lot of really really complex golang programs and it 'just works'. I would really love to get that point with python.

The LAST thing you want to do is ever muck around with distro-packaged modules. You don't want to change them, update them, patch them, or do anything. How distro packaging works it is extremely fragile to any third party changes. This is true in my experience for Perl, Emac packages, and python modules. The quickest way to introduce nasty bugs and issues for end users is to try to install stuff that could show up system-wide.

> Why not drop those static binaries into an RPM or Debian package then?

It's not something you get 'for free' just by creating a bunch of rpms and deb packages.

If you want to take advantage of validating signatures and automated updates then you have to setup your own repository for each distro you want to have it be used by. The end user has to add the repository either by hand and use distro-specific things for importing signing keys or you have to build and provide additional rpms/debs that sets up their repo configs and signing keys. Each distro is different. Then you have to test that stuff for each distro and version to make sure it works. And you'll still have to provide binary-only downloads and signature files for people using Arch/Gentoo/Docker or whatever.

For my purposes things I make I send out to people for automation.. like doing migrations and upgrading for clusters of virtual machines. It's all very environment-specific and I can send people a email or write a ticket with a tarball attachment they can extract and it'll probably work regardless how they have their desktop or jump box setup. If something goes wrong I can fix it and send it back out to them again. If they want to fix it themselves I have instructions and code in git.

If I was distributing for public consumption I would definitely take a look at something like Suse's build services for multi-distro rpms and such things. There is probable a nice way to make it all be very nice with little effort, but I haven't investigated because it's not really that helpful for me my users at this point of time.