Dub, Cargo, Go, Gradle, Maven

[Pjotr Prins]

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.