Omnibus – Dependency Isolation Without Docker
blog.barricade.io
blog.barricade.io
And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way.
At the end of the day, users care most about getting stuff done. I am the author of a popular app that is written in C++ and uses Boost. Many users literally begged me to bundle Boost because installing Boost is so much of a pain for them.
Yes, you've identified a bad trend. I am trying to raise awareness to stop it.
>And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way.
You can actually use Guix to export the closure of the build and distribute that, if that's your thing. We do this for Guix itself to greatly simplify the installation process for new users, though for your use-case there would be some adjustment needed. The resulting binary distribution would work on any GNU/Linux system. Nix additionally offers OS X support. But yes, not everyone's use-case can be covered by Guix right now, but I strongly feel it's the direction we should be moving in.
It is not The Answer, it's just an answer until we (and I'm glad to see there are people like yourself on the case) can do better.
Linking strategy is a totally orthogonal concern to package management, though I prefer static linking myself for not having to deal with the broader issues of the shared library namespace.
If I'm deploying a newer version of some project, which depends on a more recent version of a database which requires some schema migration (e.g. my PostGIS types are out of date and need upgrading), what happens to my data?
This is a frequently asked question. Nix/Guix do not interact with such files, and we make it a point to differentiate between stateful and stateless. Nix and Guix manage the stateless, deterministic stuff, and system services or other mechanisms manage the stateful stuff. For example, there's a postgresql package in Guix, but installing it doesn't create a db cluster in /var/lib, it just installs the binaries, docs, etc to the user's package profile. However, GuixSD, the distro built on Guix, comes with a postgresql system service that creates the system db cluster before launching the postgresql server. In other words, stateful things are handled at a different layer than the packaging layer.
If a new version of an application requires a schema migration, then that would be something for a system service to perform with the updated binaries from the package manager. You still need to take care to back up your databases, home directories, etc.
Some projects may benefit from using Omnibus; being able to produce deliverables which are just installed by the package manager. However, there is a significant learning curve and investment of time required for the debugging process in order to get your package building with Omnibus.
I finally said screw all that and I've resorted to shell scripts + packer building my images on amazon. Now my builds don't require a complicated omnibus builder host to be configured, or even ruby to be installed and god damnit, I don't have to worry about doing a bundle update to get the latest chef-sugar or omnibus gem to get it to work.
I'm tired of these complicated systems. Every new piece of tech in your stack should be considered carefully. I could barely explain Omnibus to my dev team, even though I knew exactly how it worked and how all the packages were built on every build.
Omnibus is a great project with a lot of contributors, but users beware - it comes at a price of time and complexity.
It is without a doubt most useful when you do not control the environment where your code is going to be deployed.