The idea that you can easily type a command and be quickly dumped into a development environment for some software your system runs is amazing. I think it’s something that actually brings people closer towards some of the ideals of GNU or Open Source and better lets you take advantage of everything being open source. (Aside: I think this is also great about Emacs; you can easily jump to the source of most things and there’s usually a way to hack or modify or inspect or debug them immediately).
One thing I couldn’t work out how to do in guix was to go the whole way through. Something like:
1. Install / use some program
2. Find some bug or potential improvement
3. Run the command to be dumped into a dev environment for that
4. Fix or investigate the bug; or implement the improvement
5. (The step I don’t know how to do) Use your fixed/improved version in your operating system
6. (Also don’t know how to leverage guix for this) Share your improvements with others
It feels like 5 is somewhat at odds with how guix is meant to work as step 4 is so mutation-heavy, but it also feels like something that an OS which wants to be as gnu as possible should really want to support. And gui should be able to make it safer too by giving you rollbacks. Maybe there’s an easy way to do it and I just don’t know it?
(note: usually packages are installed as regular user into your user profile)
See also section "Package Transformation Options" in "info guix".
For step 6, send a mail with the patch to the package definition (in an existing scm file in https://git.savannah.gnu.org/git/guix.git ) to the guix-devel mailing list. But whatever you did manually to get yourfixedversion_src.tar.gz you now should automate by programming the patching process in Scheme instead--editing a guix checkout (usually just to add: (add-after 'unpack 'patch-problematic-stuff-4711 (lambda _ (substitute* "somefile" (("regex1") "replacement"))))). For more complicated fixes, add a patch to the guix checkout and make Guix use it in Scheme (and contribute it to the actual foo upstream project--which we usually do anyway).
See section "Contributing" in "info guix".
Further automation welcome-- and probably not that difficult to add. Just keep in mind that each package build is in its own container (it's kinda like Docker would be)--so no mixing text editor and building and weird user-defined pauses (for example there is no text editor in the build container).
I guess I wish that the custom install were as easy as guix shell (and that it would also do sensible things like recompiling dependencies if you modified a library). But maybe it’s actually hard to do for reasons I haven’t thought about.
I guess I wish that the custom install were as easy as guix shell (and that it would also do sensible things like recompiling dependencies if you modified a library).
The reason for the seemingly duplicate "foo" in the "--with-" options is that those "--with-" can apply to dependencies if you specify the right package there (so in the example, something else than "foo"--like something foo depends on). In that case it will recompile everything that needs recompiling.
But maybe it’s actually hard to do for reasons I haven’t thought about.
It can easily be that we all made our own workarounds and so while it would be easy to add a nice frontend, nobody has a need.
So if you do think of a nice way, please try to do it.
For example we have some bias for emacs: inside emacs the guix development is very comfortable (we have and ship our own extensions for emacs). But that doesn't help you if you are not an emacs user.
The Guix package repo is a monorepo (see below)--all those packages have to work (and be tested) together.
From time to time I do think it would be nice to reduce barrier of entry by automating existing package editing inside a shell script we could ship:
(the guix edit is NOT in the guix shell environment, therefore you have an editor)
... but so far it never makes it out of my head to an actual script shipped with guix :(
If we did make it--what would the package it would be in be called? Or should it be a subcommand of the "guix" command?
That said, if you want to make your own NEW packages, that's easy and well-supported. You can put a guix.scm whereever you like and lots of guix stuff will pick it up automatically.
The idea that you can easily type a command and be quickly dumped into a development environment for some software your system runs is amazing. I think it’s something that actually brings people closer towards some of the ideals of GNU
This is exactly right, and I think it's one of the coolest things about Guix. Guix System (the full OS based on Guix) seems almost like the GNU that was dreamt of before Linux. It even has an option built on the Hurd kernel, and it uses an init system and initrd images based on Guile Scheme, which is both the language used for Guix itself and as the extension language for GNU projects.
Guix definitely advances the whole
Learn one simple, high-level language and you can hack on every aspect of your system
idea further than we've seen on any modern/contemporary system.
Aside: I think this is also great about Emacs; you can easily jump to the source of most things and there’s usually a way to hack or modify or inspect or debug them immediately
I think Emacs is definitely an inspiration, or a model of the virtues intended.
Comments
The idea that you can easily type a command and be quickly dumped into a development environment for some software your system runs is amazing. I think it’s something that actually brings people closer towards some of the ideals of GNU or Open Source and better lets you take advantage of everything being open source. (Aside: I think this is also great about Emacs; you can easily jump to the source of most things and there’s usually a way to hack or modify or inspect or debug them immediately).
One thing I couldn’t work out how to do in guix was to go the whole way through. Something like:
1. Install / use some program
2. Find some bug or potential improvement
3. Run the command to be dumped into a dev environment for that
4. Fix or investigate the bug; or implement the improvement
5. (The step I don’t know how to do) Use your fixed/improved version in your operating system
6. (Also don’t know how to leverage guix for this) Share your improvements with others
It feels like 5 is somewhat at odds with how guix is meant to work as step 4 is so mutation-heavy, but it also feels like something that an OS which wants to be as gnu as possible should really want to support. And gui should be able to make it safer too by giving you rollbacks. Maybe there’s an easy way to do it and I just don’t know it?
For step 5:
guix install foo --with-source=foo=yourfixedversion_src.tar.gz
Or:
guix install foo --with-patch=foo=yourpatch.patch
(note: usually packages are installed as regular user into your user profile)
See also section "Package Transformation Options" in "info guix".
For step 6, send a mail with the patch to the package definition (in an existing scm file in https://git.savannah.gnu.org/git/guix.git ) to the guix-devel mailing list. But whatever you did manually to get yourfixedversion_src.tar.gz you now should automate by programming the patching process in Scheme instead--editing a guix checkout (usually just to add: (add-after 'unpack 'patch-problematic-stuff-4711 (lambda _ (substitute* "somefile" (("regex1") "replacement"))))). For more complicated fixes, add a patch to the guix checkout and make Guix use it in Scheme (and contribute it to the actual foo upstream project--which we usually do anyway).
See section "Contributing" in "info guix".
Further automation welcome-- and probably not that difficult to add. Just keep in mind that each package build is in its own container (it's kinda like Docker would be)--so no mixing text editor and building and weird user-defined pauses (for example there is no text editor in the build container).
I guess I wish that the custom install were as easy as guix shell (and that it would also do sensible things like recompiling dependencies if you modified a library). But maybe it’s actually hard to do for reasons I haven’t thought about.
The reason for the seemingly duplicate "foo" in the "--with-" options is that those "--with-" can apply to dependencies if you specify the right package there (so in the example, something else than "foo"--like something foo depends on). In that case it will recompile everything that needs recompiling.
It can easily be that we all made our own workarounds and so while it would be easy to add a nice frontend, nobody has a need.
So if you do think of a nice way, please try to do it.
For example we have some bias for emacs: inside emacs the guix development is very comfortable (we have and ship our own extensions for emacs). But that doesn't help you if you are not an emacs user.
The Guix package repo is a monorepo (see below)--all those packages have to work (and be tested) together.
From time to time I do think it would be nice to reduce barrier of entry by automating existing package editing inside a shell script we could ship:
(the guix edit is NOT in the guix shell environment, therefore you have an editor)... but so far it never makes it out of my head to an actual script shipped with guix :(
If we did make it--what would the package it would be in be called? Or should it be a subcommand of the "guix" command?
That said, if you want to make your own NEW packages, that's easy and well-supported. You can put a guix.scm whereever you like and lots of guix stuff will pick it up automatically.
You also need to subscribe to the mailing list or your emails will be ignored.
That's not true. I've never subscribed to the mailing list and all patches I've sent were applied.
This is exactly right, and I think it's one of the coolest things about Guix. Guix System (the full OS based on Guix) seems almost like the GNU that was dreamt of before Linux. It even has an option built on the Hurd kernel, and it uses an init system and initrd images based on Guile Scheme, which is both the language used for Guix itself and as the extension language for GNU projects.
Guix definitely advances the whole
idea further than we've seen on any modern/contemporary system.
I think Emacs is definitely an inspiration, or a model of the virtues intended.