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.
