Hacker News Reader

Comment by davexunit | Hacker News Reader

'guix shell' is killer. I use it for all my projects and one-off experiments. I also hook it up to Emacs 'M-x compile' so that compilation happens in the context of the guix shell. Beyond the simple command line package specification, you can add a guix.scm file to the root of your project repo and fill it with code that specifies all the packages needed for a development environment. Some of my guix.scm files are simple lists of existing packages, others are full of custom code to modify existing packages or define new ones. No matter how simple or complex it is behind the scenes, I just run 'guix shell' and get on with working on my project.

View on HN

You might be interested in buffer-env, it can automatically load an environment on a buffer-to-buffer basis and make it appear as though it were globally installed. No manual "guix shell ... -- ..." calls needed.

Could you elaborate a bit on how this works? Am a longtime emacs user and very motivated to get this working!

I wrote down my notes on how to use it here: https://amodernist.com/texts/emacs-guix.html.

Thank you!!

Thanks, I've been meaning to check it out, so long as I can integrate guix shell with it.

On a high level, this reads like what Docker is kind of achieving.

{docker, nix, guix} take any two. What are their differences?

Guix shell does not by default work inside a container. There is --container, as mentioned in the article, but by default guix shell is setting up a clean shell to work in, which has the dependencies available.

A guix.scm file is a mostly declarative file, where one specifies the "what" not the "how", in contrast to a Dockerfile for example, where one writes sequential steps to take, to install all that is needed, which is of course much more prone to making mistakes. In guix one relies on the package specifications, which are already in guix for the dependencies and guix' machinery to process them. In docker one uses the directives offered by docker to write a Dockerfile instead.

I guess one could say guix is a bit higher level than docker and does not require you to know how to install something you depend on. On the other hand you need to know about guix' way of describing a package, if you want to create one. But for mere dependency specification, guix is much simpler than writing a Dockerfile.

Just to emphasize, the lack of docker is a good thing - full virtualization is nice but as with anything comes at the cost of overhead, complexity (you need to connect things between docker instances and disparate data sources? Probably need some fancy solution with its own quirks).

I haven't used it yet, but I love the concept - I use small environmental scripts all the time, explicitly to not have to deal with vms, this sounds like it is much more flexible and crucially much more reproducable.

Any pointers to your setup?

As zelphirkalt pointed out, one project I use with guix shell is named Chickadee. It's a little game dev library.

Here is the guix.scm file: https://git.dthompson.us/chickadee.git/tree/guix.scm

Here is another project (a static site generator) with a much simpler guix.scm file: https://git.dthompson.us/haunt.git/tree/guix.scm

In both cases, this same file can be used to create a development environment via 'guix shell', build from scratch in an isolated environment (handy to run before a release) via 'guix build', and it can even be installed with 'guix package'. It's super handy.

I was looking for an example as well, when I saw the nickname of the GP. He created a nice project named Chikadee and the source code can be seen at https://git.dthompson.us/chickadee.git/tree/, where you can also find the guix.scm file.

Reply on news.ycombinator.com