On Thursday, 15 February 2018 at 04:11:51 UTC, Graham St Jack wrote:
Maybe a compromise position would be for a package management system to define an interface through which it can do things like:

* Discover what the external dependencies are,

* Provide those external dependencies, and

* Invoke a full build.

Then, any number of build systems (and deployment systems?) could be adapted to work with the package management system.

That is exactly what GNU Guix offers. With support for isolated builds, continuous integration testing, and containers thrown in, if you want that. People misunderstand Guix somewhat because it presents itself as a 'package manager' and even distribution in its own right. But actually it is a dependency manager that can run on top of any system.

I am writing a BLOG on how to use Guix for Python development using its package managers and even dependency injection (say a choice of BLAS libraries or LLVM in the case of D). When that is done I could do a D writeup if there is enough interest.

I am sure some people roll their eyes when I mention GNU Guix. But, hey, if you are an Emacs or gcc user you may be able to afford to pay attention to long running GNU projects.

To anticipate real criticism: there are currently two main issues: (1) GNU Guix runs on Linux and (2) the default requires a running build daemon.

About (1) since this is a libre project the focus is on Linux and Hurd. It is actually fairly straightforward to port Guix to other OS's. Nix, which shares the build daemon with Guix, runs on OSX and Windows.

About (2) the daemon can run unprivileged. I have written documents about running Guix without root access (I need it on HPC). It is just a little more involved.

Anyway, I don't really care who uses Guix or who uses something else. I expect 99.9% of people to ignore these ideas. Just to say I simply use it to make my own life easier. The point here is that I understand what it took to create Guix and it is non-trivial. We can reuse this functionality very easily and take control over the dependency graph. You get reproducible builds, easy mixing of LLVM versions and many other features. Fixing (1) above is much easier than recreating something like Guix from scratch. And since Guix is distribution agnostic you can use it on any old CentOS, Debian, Ubuntu... you name it. The only thing Guix uses is the *running* kernel API. Even glibc and the linked library loader come with Guix (and you can easily run multiple versions of said libraries). That is a full and deep dependency graph.

With Guix I do not need dub or pip or gems. It is trivially easy to manage dependencies. Still I can use those package managers if I want to. In a controlled fashion.

PS The JVM world has the advantage of being a clear and isolated system. Good news is that Guix supports that too and it provides an awesome libre bootstrap from source. If you care about the free and open in FOSS that is a huge selling point in a world that appears to increasingly bootstrap from binary blobs.

It is easy to write-off such ideas. But if you don't try it, you don't understand it. Similar to the D vs other language discussions. I am not going to say Guix is easy. Similar to the fact that D is not easy. But you can gradually get in and learn to appreciate the great engineering under the hood. That goes for Nix too. Guix and Nix still share the build daemon, though they have become completely different systems with different characteristics.

If you want to try Guix - I am here to support you.

Reply via email to