Ludovic Courtès

@provectus Oh yes, that makes total sense, sorry for the misguided suggestion.

@provectus The easiest option to create a Hurd image with Guix is by running ‘guix system image -t hurd64-qcow2 config.scm’, where ‘config.scm’ contains an OS configuration for the Hurd 👇
https://guix.gnu.org/manual/devel/en/html/_node/Invoking-guix-system.html#index-image_002c-creating-disk-images

This cross-compiles the entire image contents, so you have to restrict yourself to packages that can be cross-built. A good starting point is:
https://codeberg.org/guix/guix/src/branch/master/gnu/system/examples/bare-hurd64.tmpl

Kudos to the author! It’s unusual to see posts like this that are pleasant to read *and* dive deep into not one but two systems!

I have a clearer view of flakes now and how it corresponds (or not) to the things I know better. :-)

@csantosb Funny hack!

💡 Did you know that the “abomination” initially went the other way around? 👇
https://archive.softwareheritage.org/browse/revision/60c21332d2092cf16feee5bfc384ca4c94c15a23/#swh-revision-changes

@RumRunningDevil The usual method is with ‘guix import go --recursive’. (There are currently more than 2k Go packages in Guix that were created like this.)

Does that work for you?

@fishinthecalculator Woow, nice!

I think a key difference with Docker Compose is that this is very much static: ‘guix compose import’ creates a Guix System config snippet.

Would Be Nice™ to also hook up the ‘docker-compose.yml’ parser to create containers on-the-fly, managed by a Shepherd instance, in the spirit of Swineherd:
https://github.com/BIMSBbioinfo/swineherd

That would more closely match the developer use case, I guess.