guix: init at 1.4.0

[cafkafk]

Description of changes

This is a work in progress to add guix to nix once again.

Things done

• Built on platform(s)
  • x86_64-linux (native, aarch64-linux cross)
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[wegank]

Currently stuck at build not picking up guile-git for some reason.

Probably because guile defaults to guile_2_2 in nixpkgs? Maybe an override would help?

EDIT: guile now defaults to guile_3_0, see #247013.

[viperML]

I just want to mention that @foo-dogsquared packaged guix some time ago:

https://github.com/foo-dogsquared/nix-overlay-guix/blob/master/pkgs/guix.nix

[cafkafk]

I just want to mention that @foo-dogsquared packaged guix some time ago:

https://github.com/foo-dogsquared/nix-overlay-guix/blob/master/pkgs/guix.nix

Ohh, that's saves some work, why isn't it in nixpkgs (should guix not be nixpkgs for some reason)?

[foo-dogsquared]

Hello! I do plan it to eventually upstream the package (and the module) in nixpkgs. (I mean there is a Nix service module in Guix so why not do the same here?)

It's just that the Guix package in the overlay is not exactly complete which is why it's not in nixpkgs yet. Usable, but not complete where everything works. Also, testing the package for it to be acceptable in nixpkgs is time-consuming. Basically, I bit off more than I can chew and eventually my time was spent somewhere else. More hands on packaging it is definitely appreciated!

[cafkafk]

It's just that the Guix package in the overlay is not exactly complete which is why it's not in nixpkgs yet. Usable, but not complete where everything works. Also, testing the package for it to be acceptable in nixpkgs is time-consuming. Basically, I bit off more than I can chew and eventually my time was spent somewhere else. More hands on packaging it is definitely appreciated!

Looking over it, my time would probably be best spent getting some of the guile packages in nixpkgs? Perhaps adding https://github.com/foo-dogsquared/nix-overlay-guix/blob/master/pkgs/guile/build-guile-module.nix?

[foo-dogsquared]

Looking over it, my time would probably be best spent getting some of the guile packages in nixpkgs.

Ideally buildGuileModule would be imported first (which I elaborate why later) so you don't have to do more work but you could do that if you want.

Perhaps adding https://github.com/foo-dogsquared/nix-overlay-guix/blob/master/pkgs/guile/build-guile-module.nix?

As for buildGuileModule, I envision a restructuring of Guile modules in nixpkgs similar to Python and Lua modules where you can get modules from different versions of the interpreters (for example, python310Packages.click, python37Packages.click). The reasoning being Guix requiring Guile v3.0.0 (and later versions). I haven't got around to implement that yet. I could upstream this function first and gradually build on it, though.

That said, this should definitely go through a discussion with the community before implementing it. I'll make a mental note to file an issue later (or tomorrow) about this.

[cafkafk]

I'll make a mental note to file an issue later (or tomorrow) about this.

Did you ever get around to this?

[foo-dogsquared]

Did you ever get around to this?

No, I haven't yet. Sorry, I entirely forgot since I was in a short vacation after I made that comment. Though, I already have some notes in mind regarding how Guile packages could be structured so it shouldn't take long in this night or tomorrow morning in my time.

[cafkafk]

Sorry, I entirely forgot

NW, and no rush! Looking forward to seeing what you've thought of.

[foo-dogsquared]

Hello! I'm going to say the issue may not be filed after all. After reviewing the state of Guile ecosystem, what I'm supposed to propose which is a restructuring of Guile modules similarly to Python and Lua in nixpkgs (i.e., python38Packages..python310Packages, lua51Packages..luajitPackages) but with guile20Modules..guile30Modules and the like. But the more I look into it, the more it becomes unnecessary.

• Much of the Guile ecosystem moved into v2 to v3 unlike some other programming language with a similar transition. Being a smaller ecosystem helps for the most part to make the transition faster, I guess.
• At the time of creating buildGuileModule, it is supposed to solve some problems for Guile packaging such as wrapping the binaries and setting some appropriate search paths for certain versions but much of the problems have already been solved.
• Shortly after our conversation, Guile in nixpkgs has defaulted to Guile 3 which is one of the reasons I'm supposed to make the proposal in the first place (among other things).
• Not to mention the amount of effort for seemingly negligible benefit especially when most of the ecosystem has transitioned nicely from v2 to v3.

Much of the problems have already been addressed some time ago. You can package Guile modules just fine with stdenv.mkDerivation at this point. It's just me not keeping tabs on the state of Guile and its ecosystem (in nixpkgs and otherwise).

At this point, you could move on to upstreaming some of the packages from the overlay to nixpkgs. Feel free to add me as a co-maintainer to those upstreamed packages. Also be sure to ping me as well so you have an extra pair of eyes for review.

edit: I've recently pushed some changes to the develop branch of the overlay, you could start there if you want.

[wegank]

It seems to be working:

$ sudo result/bin/guix-daemon --build-users-group=nixbld
accepted connection from pid 730770, user weijia

$ result/bin/guix build hello --check
La dérivation suivante sera compilée :
  /gnu/store/as3n66w4nd9s0lrq8i0w6xlh58hps9p1-hello-2.12.1.drv
construction de /gnu/store/as3n66w4nd9s0lrq8i0w6xlh58hps9p1-hello-2.12.1.drv...
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
...
phase `compress-documentation' succeeded after 0.1 seconds
construction de /gnu/store/as3n66w4nd9s0lrq8i0w6xlh58hps9p1-hello-2.12.1.drv réussie
construction de /gnu/store/as3n66w4nd9s0lrq8i0w6xlh58hps9p1-hello-2.12.1.drv réussie
/gnu/store/s2qnbdlrwlx47h5p6rxlylny1259srmj-hello-2.12.1

$ result/bin/guix shell hello
$ hello
Hello, world!