Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

[zimoun]

Hi Ryan,

Thank you for your detailed explanations.  Here I try to connect the
dots between the current blocks and the picture you are drawing.


On Sat, 19 Mar 2022 at 18:18, Ryan Prior <rprior@protonmail.com> wrote:

> When I install Docker for Desktop on macOS or Windows, I do not have
> to first install a VM manager dependency like QEMU or VirtualBox. The
> installer for Docker creates and manages a VM automatically, which is
> treated as de-facto immutable and never exposed to the user at all. It
> is locked down, automatically updated, and doesn't provide the user
> any way to install new software or make changes to it. It's not like a
> distro: it provides only what's necessary to run containers, with no
> desktop, no coreutils, no SSH, no VNC, practically no userland at
> all.

>From my experience about Docker, Guix on foreign Linux distro via the
install script provides the same experience as Docker for Desktop.

For sure, the learning curve is not the same.  Because Guix is less
polished and many less tutorials are around.


About MacOs and Windows, well Docker is powered by a company so their
product is targeting a market.  Instead, Guix is powered by volunteers
working on their personal interest; well if a company is ready to invest
in Guix, I am sure it would also “work” on these platforms. ;-)


> The only point of interaction with the VM is through the Docker
> daemon. On Windows or Mac when you run `docker build` the client
> software is connecting to the daemon in the VM, sending it the build
> context, etc - but the user doesn't have to configure or manage any of
> this. And thus with each Docker command.

Well, the user manages the Dockerfile build, no?

Guix on foreign distro works the same way, no?  Instead of a Dockerfile,
it is a config.scm file.

Somehow, the workflow of Docker and Guix-on-foreign-distro is the same
from my point of view.  The main difference is robustness and
documentation, again IMHO.


> The target demographic is developers who, whether out of preference or
> for corporate compliance or some other reason, use macOS or Windows on
> their dev machine but are deploying to GNU/Linux boxen. By
> standardizing on Docker for Desktop, organizations are able to provide
> a consistent GNU toolchain to all their developers and operators,
> smoothing out the differences between platforms and decreasing
> complexity.

I agree.  About Windows, Guix should be available via WSL2, IIURC.
About MacOS… long story. ;-)


> But for a variety of reasons organizations commonly have a
> heterogeneous environment, with GNU/Linux on the server and a mix of
> free and non-free OSes on the client. They would face a much lower
> barrier to adopt if we were to offer a "Guix for Desktop" installer
> that enables uniform developer workflows, such that "guix build -f
> my-app.scm" works the same on any client, and so on for each Guix
> command.

What I miss is that your description maps one to one my use of Guix on
foreign distro with “collaborators” (mainly biologists, so similar to
the end-users described above, I guess).  Whatever their Linux distro
and their host versions are (usually Ubuntu though), we are running the
same computational stack; mainly:

    guix time-machine -C channels.scm -- shell -m manifest.scm

where channels.scm and manifest.scm live in a shared Git repo with the
other stuff.  In this case, manifest.scm provides the tools for
building, say manually.

It is similar with

    guix time-machine -C channels.scm -- build -f my-app.scm

using the Guix daemon for building.

And channels.scm can contain private collections not yet in Guix.


> This would necessarily exclude some commands, like and "guix system
> reconfigure," which are expected to mutate the user's base
> system. Installed this way, every interaction with Guix would be in a
> Guix container, with files from the host system mounted into it. If I
> ran "guix install coreutils" then the installed "ls" would be a shell
> script that runs ls inside a Guix shell in the VM, with the current
> directory mounted into it.

For instance, I have never used “guix system reconfigure” for my daily
job. :-)

On any Linux distribution,

    guix shell -C coreutils

does what you are describing.  No VM, only Linux namespace.

For sure, it leads to issues for MacOS.  Well, long story. :-)

>
> This would not be an ideal system for installing and managing software
> on a non-free OS and I wouldn't recommend using it for such: it's
> limited, carries the performance penalty of a VM, adds complexity,
> &c. But for the specific case where the end-user is a software
> engineer on a non-free OS who is building, testing, and deploying
> software using Guix, it could be excellent. You'd check out your repo,
> "guix build my-app.scm," then "guix deploy prod.scm" and off you
> go. These things happen principally in the domain where we aren't
> interacting with the host system much anyway, so the limitations
> matter little, while the benefits to people working in heterogeneous
> tech organizations are great.

I agree.  Well, Guix via Gnome boxes seems a step in that direction.  I
also agree that the story of Guix for Windows and MacOS is not so nice.
Currently, it is a strong limitation for adoption in my lab; most if not
all people run the main computer with MacOS or Windows and another
dedicated computer for “computational analysis”.

About Windows, it could be worth to maybe document what already
works. :-)


Cheers,
simon