Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/guix: init at 1.0.0 #56430

Closed
wants to merge 2 commits into from
Closed

nixos/guix: init at 1.0.0 #56430

wants to merge 2 commits into from

Conversation

@pukkamustard
Copy link
Contributor

@pukkamustard pukkamustard commented Feb 26, 2019

Add GNU Guix package manager as a NixOS module that can be enabled with the configuration services.guix.enable = true.

Todo

I would like to ask for input and assistance in how to tackle these issues.

  • Activation script causes a warning that should be prevented.
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and defining `GUIX_LOCPATH', along these lines:

     guix package -i glibc-utf8-locales
     export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

Hint on how to prevent the warning is already given. But how to do this nicely

  • Currently some setup is done using environment.shellInit. I have mixed feelings about messing with users PATH. This could be forgone and users could be required to do manual setup of their environment to use Guix (see Application Setup).

  • Related to point above: Directory in Guix profile containing info files needs to be added to INFOPATH environment variable. This is currently attempted in environment.shellInit but does not seem to work.

  • Support more platforms than just x86_64.

Futher Improvements

Bootstrap Guix

Instead of using the Guix binary tarball it would be much cooler to bootstrap Guix from a smaller bootstrap binaries.

Automated test

A NixOS test that checks functioning of Guix.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@JohnAZoidberg
Copy link
Member

@JohnAZoidberg JohnAZoidberg commented May 4, 2019

system.activationScripts.guix = ''

# copy initial /gnu/store
if [ ! -d /gnu/store ]
Copy link
Member

@JohnAZoidberg JohnAZoidberg May 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks when updatingguix-binary. Its new packaged /gnu/store doesn't get copied.
I think merging them wouldn't be harmful because the store paths don't change. I.e. we could always rsync from the package to the gnu-store. I also don't expect the daemon to be restarted a lot.

Maybe someone else has a better idea.

Copy link
Contributor Author

@pukkamustard pukkamustard May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. This might be tricky.

I think merging would be a non-op. The Guix Store database (located in /var/guix/db) would not be updated with new stuff added to /gnu/store and guix would probably garbage collect it away. The database would need to be updated, but that seems a bit far out.

Guix can install an update of the guix binary into the /gnu/store and will then use that. Weird things might happen when guix in /gnu/store is of a different version than guix in /nix/store.

Copy link
Member

@JohnAZoidberg JohnAZoidberg May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well do we want to put guix in the nix-store at all?
Maybe just add the guix in /gnu/store to PATH.

Copy link
Contributor Author

@pukkamustard pukkamustard May 6, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works! Even recommended by the Guix manual:

Make the guix command available to other users on the machine, for instance with:
# mkdir -p /usr/local/bin
# cd /usr/local/bin
# ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix

See: d95fa03


cfg = config.services.guix;

guix-binary = pkgs.stdenv.mkDerivation rec
Copy link
Member

@JohnAZoidberg JohnAZoidberg May 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd definitely split the package out into its own file. (And own commit)

Copy link
Contributor Author

@pukkamustard pukkamustard May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Now a maintainer is required. Would you be willing to fill that role @JohnAZoidberg?

I can also step in. However I am not yet on the list of maintainers and my NixOS usage is decreasing (in favor of Guix).

Copy link
Member

@JohnAZoidberg JohnAZoidberg May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah sure! I want to check out Guix - the UX of their commands seems really nice.

What made you switch?

Copy link
Contributor Author

@pukkamustard pukkamustard May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Added you as maintainer.

What made you switch?

Mostly curiosity to learn Scheme and increased interest in GNU projects and the whole philosophy behind them.

i can highly recommend the Guix reference manual. A very worthwhile read!


src = pkgs.fetchurl {
# TODO: make work on non x86_64 systems
url = "https://alpha.gnu.org/gnu/guix/guix-binary-${version}.x86_64-linux.tar.xz";
Copy link
Member

@JohnAZoidberg JohnAZoidberg May 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't have 1.0.0 and also they recommend https://ftp.gnu.org/gnu/guix/guix-binary-${version}.${pkgs.stdenv.targetPlatform.system}.tar.xz.
I think that's the correct variable for the system string - not quite sure.

Copy link
Contributor Author

@pukkamustard pukkamustard May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the URL. System string works ($pkgs.stdenv.targetPlatform.system). Also added correct SHA256s for platforms. However only tested on x86_64-linux.

ExecStart="/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild";
Environment="GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale";
RemainAfterExit="yes";
StandardOutput="syslog";
Copy link
Member

@JohnAZoidberg JohnAZoidberg May 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From systemd.exec(5)

Note that the journal daemon is usually configured to forward everything it receives to syslog anyway, in which case this option is no different from journal [the default]

Is there a particular reason why you want to force syslog?

Copy link
Contributor Author

@pukkamustard pukkamustard May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No particular reason. I used configurations from the upstream Guix template (https://git.savannah.gnu.org/cgit/guix.git/tree/etc/guix-daemon.service.in).

Maybe it is good to not force it. There is a NixOS options services.journald.forwardToSyslog. I don't know exactly what this options does but by not forcing stuff here we might prevent unintended things happening when the option is set manually.

I removed the entry StandardOutput and StandardError.

@JohnAZoidberg
Copy link
Member

@JohnAZoidberg JohnAZoidberg commented May 4, 2019

In 1.0.0 I don't get the locale warning anymore. Can you confirm?
Also for me the INFOPATH is appended. Maybe you forgot to spawn a new shell?

RemainAfterExit="yes";
StandardOutput="syslog";
StandardError="syslog";
TaskMax= "8192";
Copy link
Member

@JohnAZoidberg JohnAZoidberg May 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
TaskMax= "8192";
TasksMax= "8192";

Copy link
Member

@JohnAZoidberg JohnAZoidberg May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should absolutely include the comment that they also use upstream in guix:

# See <https://lists.gnu.org/archive/html/guix-devel/2016-04/msg00608.html>.
# Some package builds (for example, go@1.8.1) may require even more than
# the default of 1024 tasks.

Copy link
Contributor Author

@pukkamustard pukkamustard May 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect. Added.

Copy link
Member

@JohnAZoidberg JohnAZoidberg May 6, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name of the option is still wrong ;)

@pukkamustard
Copy link
Contributor Author

@pukkamustard pukkamustard commented May 5, 2019

Thanks for the review!

Upgraded to 1.0.0, added some changes, rebased on master and force-pushed.

In 1.0.0 I don't get the locale warning anymore. Can you confirm?

Negative. Still get the same error. However, I'm still on NixOS 18.09, maybe something changed in 19.03?

Also for me the INFOPATH is appended. Maybe you forgot to spawn a new shell?

Aha, yes! That seems to have been the issue. Added another commit (will squash before merge).

@pukkamustard pukkamustard changed the title nixos/guix: init at 0.16.0 nixos/guix: init at 1.0.0 May 5, 2019
@JohnAZoidberg
Copy link
Member

@JohnAZoidberg JohnAZoidberg commented May 6, 2019

I'm working on trying to build guix from source. But we're going to need at least 7 more guile modules for that and also patch gnutls. I think that's out of scope for this PR.

@JohnAZoidberg
Copy link
Member

@JohnAZoidberg JohnAZoidberg commented May 6, 2019

Negative. Still get the same error. However, I'm still on NixOS 18.09, maybe something changed in 19.03?

Did you remove /gnu/store and /lib/guix and then rebuild NixOS?
Because otherwise it'll use the old version - see my comment about rsync.
Can you check which guix version you're using?
Previously guix showed the warning on all invocations of the command. Is that the case for you too?

@pukkamustard
Copy link
Contributor Author

@pukkamustard pukkamustard commented May 6, 2019

Did you remove /gnu/store and /lib/guix and then rebuilt NixOS?

No, I didn't. And yup, after removing /gnu/store and /var/guix I don't get the locale warning any more.

@Infinisil

This comment was marked as off-topic.

@JohnAZoidberg
Copy link
Member

@JohnAZoidberg JohnAZoidberg commented May 24, 2019

@Infinisil Your comment was supposed to be for #61742?

@Infinisil
Copy link
Member

@Infinisil Infinisil commented May 24, 2019

Ohhh indeed, sorry for that

@jb55
Copy link
Contributor

@jb55 jb55 commented Aug 16, 2019

Trying this out now.

What do you think about:

diff --git a/nixos/modules/services/development/guix.nix b/nixos/modules/services/development/guix.nix
index 8ca07d755f0..a98716536d6 100644
--- a/nixos/modules/services/development/guix.nix
+++ b/nixos/modules/services/development/guix.nix
@@ -31,6 +31,7 @@ in {
   };
 
   config = mkIf (cfg.enable) {
+    environment.systemPackages = [ cfg.package ];
 
     users = {
       extraUsers = lib.fold (a: b: a // b) {} (builtins.map buildGuixUser (lib.range 1 10));

@pukkamustard
Copy link
Contributor Author

@pukkamustard pukkamustard commented Aug 19, 2019

Trying this out now.

What do you think about:

diff --git a/nixos/modules/services/development/guix.nix b/nixos/modules/services/development/guix.nix
index 8ca07d755f0..a98716536d6 100644
--- a/nixos/modules/services/development/guix.nix
+++ b/nixos/modules/services/development/guix.nix
@@ -31,6 +31,7 @@ in {
   };
 
   config = mkIf (cfg.enable) {
+    environment.systemPackages = [ cfg.package ];
 
     users = {
       extraUsers = lib.fold (a: b: a // b) {} (builtins.map buildGuixUser (lib.range 1 10));

We did that to begin. Which causes some problems (see #56430 (comment)).

Idea is to always just use the version of guix that is in /gnu/store (and not /nix/store).

The git history of this is lost as I rebased and squashed the commits (in anticipation of merge). That was slightly stupid of me. Sorry.

@Josh-Tilles
Copy link

@Josh-Tilles Josh-Tilles commented Aug 19, 2019

@pukkamustard: FYI GitHub still keeps the overwritten history accessible for at least a little while: https://github.com/NixOS/nixpkgs/commits/54f47499e8f77d9719bdb208fdb1925b09291f39

(Also, if it matters, I'd bet that you could still inspect and/or recover the old state of your branch locally via git reflog.)

I hope that's helpful!

@Emiller88 Emiller88 mentioned this pull request Apr 20, 2020
10 tasks
@bqv
Copy link
Contributor

@bqv bqv commented Apr 20, 2020

Safe to assume this has been abandoned

@mohe2015 mohe2015 mentioned this pull request Dec 10, 2021
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants