5 ms·

Write Guix package definitions in a breeze: Introducing Guix Packager

156 points by pabs3 3y ago

rodlette 3y ago
Great, and unexpected for Guix whose community and development seems heavily oriented to Emacs. One day I hope to return to Guix, I've never had such high introspection ability as with Guix.
- tetris11 3y ago
  I wish there was a way to step through the build phases of a package when debugging , similar to how one can use edebug on Emacs lisp functions. Currently, one has to source the failed build environment and hope they're replicating the same steps
- BaculumMeumEst 3y ago
  > I've never had such high introspection ability as with Guix. I actually feel the opposite, the fact that guile does not have edebug-style step debugging support or better tooling in general in Emacs, when both are GNU projects, is nutty to me. Makes more sense to stick to Nix IMHO because of the better package ecosystem, bigger community, and general pragmatism.
zaphar 3y ago
Guix has a more palatable language than nix to me. However I have pretty much no interest in interacting with gnu projects. I don't share the ideology strong enough to put up with it. So it stays in the "cool tech, won't use" category for me.
- tetris11 3y ago
  I had the same hangups, with Guix being way easier to grok than Nix. The non-guix repository and their substitute has you covered in the non-gnu side of things. You can use a regular kernel (read:not linix-libre) and it downloads all the required microcode and drivers.
  - SuperSandro2000 3y ago
    There shouldn't be much difference between understanding nix and guix, it is basically the same idea.
    - pasc1878 3y ago
      Understanding yes but language wise no. Guix is a known language scheme. nix is off - I can't work out what parameters are needed for any one function call they all appear to be in a global namespace. Unfortunately I need to be able to use non Linux systems
      - hamandcheese 3y ago
        > nix is off - I can't work out what parameters are needed for any one function call they all appear to be in a global namespace. If you are talking about something you saw in the nixpkgs repo, then that is probably the callPackage design pattern [0], which is basically a form of automatic dependency injection. It definitely made it hard for me to grok how nixpkgs package definitions worked at first - there was so much stuff getting injected dynamically, without any trace of where those dependencies lived. The callPackage pattern is an important piece that allows you to override a dependency with a different version, though, which is essential when customizing existing packages for your own needs. [0]: https://nixos.org/guides/nix-pills/callpackage-design-pattern https://nixos.org/guides/nix-pills/callpackage-design-patter...
        pasc1878 3y ago
        No in setting up a flake to configure my system but yes callPackage seems odd as well
        SAI_Peregrinus 3y ago
        I'd say Nix-the-language isn't that hard or weird. Nixpkgs-the-standard-library is much, much harder, and basically undocumented. Nixpkgs-the-repository is nice and search.nixos.org works well.
- SuperSandro2000 3y ago
  [flagged]
  - Geezus_42 3y ago
    [flagged]
- rowanG077 3y ago
  It's the opposite to me. Guile is an exercise in pain and suffering to read. While nix is definitely not perfect it's essentially json with some cherries on top.
  - soraminazuki 3y ago
    There's definitely a huge gap in the perception and the actual learning cost of the language part of Nix. There's few things to know about the language: JSON data types, functions, conditionals, and a small number of operators (arithmetic, concatenation, etc.). But there's so many people drawing comparisons with Haskell for, uh, apparently no reason other than to make it seem harder than it actually is.
    - spott 3y ago
      They compare them because Haskell is probably the most famous language with a function currying syntax. That is pretty much where the similarities end though.
    - femiagbabiaka 3y ago
      Hrm, I disagree. I think a functional language is a difficult transition, but the transition is worth it. If you want to be able to do things idiomatically in Nix and understand what you’re doing, there is a learning curve. It’s not a higher learning curve than a computer science bachelor will allow you to push past, but many people don’t have that background either. Quality training materials bridge that gap. If Rust and Haskell can do it, Nix can too.
- deleted 3y ago
  [deleted]
chem83 3y ago
Anything similar for nix?
- 1una 3y ago
  https://github.com/nix-community/nix-init https://github.com/nix-community/nix-init
- Geezus_42 3y ago
  There is nix-gui, but development appears to be dead. It seems like most of the community is focused on flakes, with things like the recent announcement of flake hub allowing them to be shared more easily. So we'll have packages of packages, hopefully without all the duplicate dependencies that currently exist.
_benj 3y ago
I hope to find a more consistent use for guix, is just that I mostly forget about it. My default package manager (xbps) has pretty much everything I need and the rest are either so obscure that I need to patch and compile by hand or are proprietary stuff that I just run an AppImage and are done. I had a use for it sometime ago that I needed to compile Tcl, and it was a breeze to do! But outside of such niche things I haven’t found a use for guix
- rgoulter 3y ago
  Coming from Nix (guix's more popular, but less freedom-focused cousin).. I think part of what makes Nix "next generation" is that its functionality allows for more powerful use than "install/upgrade/uninstall package". It's neat to be able to use some program without having to install/uninstall it. I find it useful to be able to programmatically declare a set of packages (& lock their versions) that I want available when working on a project.
  - f1refly 3y ago
    guix allows the user to do those things as well. Ephemeral shells with packages made available and specific environment declarations as a file are both documented and mature.
    - piperswe 3y ago
      They seem to have been pointing at Nix since they're more familiar, but acknowledging that Guix is similar in most regards. ("guix's more popular, but less freedom-focused cousin")
  - herewulf 3y ago
    Look at `guix shell` and manifest.scm. `guix shell --container` is also very useful.
- georgyo 3y ago
  Guix is very focused on "free" software and as such is very limiting. IE, if you want to use Discord, Slack, or Steam on guix you're going to have to figure that out yourself. Nix makes this much easier and you're much more likely to find ready made packages for even esoteric software. Nix has over 3 times as much software as Guix. Nix also goes for a lot more composability than guix with nix flakes. It makes it nearly trivial to package any software you want. You may want to give Nix a try if you had trouble with Guix.
0x69420 3y ago
i find myself conflicted: - on the one hand you have the general warm fuzzy feelings associated with a considerately-designed graphical tool to lower a barrier to entry - and the fact that this tool was as trivial to implement as a cursory glance at the repo suggests vindicates the whole guix/nix declarative packaging idea. the ease with which ten lines in a text editor turned a new piece of software into a first-class citizen on my system was the thing that hooked me on nix forever but that's just it: is this really lowering the barrier to entry all that much? the audience guixsd/nixos is courting is someone sick and tired of managing config files strewn across the filesystem. by definition that is someone who knows how to operate a text editor, at which point "look at how few keystrokes/memorised file paths you need on our system vs debian/arch/whatever to gain the same thing" feels like enough of a sales pitch in terms of attention economy, this is like going "what costs you a dollar on debian costs you a dime here... hey check this out now it's 9 cents if you want. neat, huh?"
- Guvante 3y ago
  Writing your first one can be brutal. While using pre-existing packages can be super easy the syntax to make a package is not.
- James_K 3y ago
  I can see myself using this even though I know how to do most of this stuff. I don't have the exact syntax of a package memorised and I think this is probably the easiest way to write one. It doesn't have to be revolutionary, just convenient.
linschn 3y ago
Slight OT, but while we are on the monthly guix topic here, let me shamelessly plug https://the-dam.org/ https://the-dam.org/, a public-access server running GNU Guix. It will let you try it out, and chat with other individuals who are also curious about guix. An update is coming "soon" where you'll be able to mount 9P2000.L servers from guix containers, something that is currently impossible due to Linux mount namespaces not allowing anything but basically fuse. You'll be able to try all the new packages you'll create with the GUI tool from TFA.
- deleted 3y ago
  [deleted]
- yjftsjthsd-h 3y ago
  > An update is coming "soon" where you'll be able to mount 9P2000.L servers from guix containers, something that is currently impossible due to Linux mount namespaces not allowing anything but basically fuse. Isn't there a 9P FUSE client to bridge the gap?
aidenn0 3y ago
I don't use Guix, but I do use Nix, and packaging is by far the easiest thing to write in it (perhaps but surprisingly). OS modules, environments, and dev-shells are all where I would like some help...

156 points by pabs3 3y ago

Great, and unexpected for Guix whose community and development seems heavily oriented to Emacs. One day I hope to return to Guix, I've never had such high introspection ability as with Guix.

tetris11 3y ago
I wish there was a way to step through the build phases of a package when debugging , similar to how one can use edebug on Emacs lisp functions. Currently, one has to source the failed build environment and hope they're replicating the same steps
BaculumMeumEst 3y ago
> I've never had such high introspection ability as with Guix. I actually feel the opposite, the fact that guile does not have edebug-style step debugging support or better tooling in general in Emacs, when both are GNU projects, is nutty to me. Makes more sense to stick to Nix IMHO because of the better package ecosystem, bigger community, and general pragmatism.

zaphar 3y ago

Guix has a more palatable language than nix to me. However I have pretty much no interest in interacting with gnu projects. I don't share the ideology strong enough to put up with it. So it stays in the "cool tech, won't use" category for me.

tetris11 3y ago
I had the same hangups, with Guix being way easier to grok than Nix. The non-guix repository and their substitute has you covered in the non-gnu side of things. You can use a regular kernel (read:not linix-libre) and it downloads all the required microcode and drivers.
- SuperSandro2000 3y ago
  There shouldn't be much difference between understanding nix and guix, it is basically the same idea.
  - pasc1878 3y ago
    Understanding yes but language wise no. Guix is a known language scheme. nix is off - I can't work out what parameters are needed for any one function call they all appear to be in a global namespace. Unfortunately I need to be able to use non Linux systems
    - hamandcheese 3y ago
      > nix is off - I can't work out what parameters are needed for any one function call they all appear to be in a global namespace. If you are talking about something you saw in the nixpkgs repo, then that is probably the callPackage design pattern [0], which is basically a form of automatic dependency injection. It definitely made it hard for me to grok how nixpkgs package definitions worked at first - there was so much stuff getting injected dynamically, without any trace of where those dependencies lived. The callPackage pattern is an important piece that allows you to override a dependency with a different version, though, which is essential when customizing existing packages for your own needs. [0]: https://nixos.org/guides/nix-pills/callpackage-design-pattern https://nixos.org/guides/nix-pills/callpackage-design-patter...
      - pasc1878 3y ago
        No in setting up a flake to configure my system but yes callPackage seems odd as well
        SAI_Peregrinus 3y ago
        I'd say Nix-the-language isn't that hard or weird. Nixpkgs-the-standard-library is much, much harder, and basically undocumented. Nixpkgs-the-repository is nice and search.nixos.org works well.
SuperSandro2000 3y ago
[flagged]
- Geezus_42 3y ago
  [flagged]
rowanG077 3y ago
It's the opposite to me. Guile is an exercise in pain and suffering to read. While nix is definitely not perfect it's essentially json with some cherries on top.
- soraminazuki 3y ago
  There's definitely a huge gap in the perception and the actual learning cost of the language part of Nix. There's few things to know about the language: JSON data types, functions, conditionals, and a small number of operators (arithmetic, concatenation, etc.). But there's so many people drawing comparisons with Haskell for, uh, apparently no reason other than to make it seem harder than it actually is.
  - spott 3y ago
    They compare them because Haskell is probably the most famous language with a function currying syntax. That is pretty much where the similarities end though.
  - femiagbabiaka 3y ago
    Hrm, I disagree. I think a functional language is a difficult transition, but the transition is worth it. If you want to be able to do things idiomatically in Nix and understand what you’re doing, there is a learning curve. It’s not a higher learning curve than a computer science bachelor will allow you to push past, but many people don’t have that background either. Quality training materials bridge that gap. If Rust and Haskell can do it, Nix can too.
deleted 3y ago
[deleted]

chem83 3y ago

Anything similar for nix?

1una 3y ago
https://github.com/nix-community/nix-init https://github.com/nix-community/nix-init
Geezus_42 3y ago
There is nix-gui, but development appears to be dead. It seems like most of the community is focused on flakes, with things like the recent announcement of flake hub allowing them to be shared more easily. So we'll have packages of packages, hopefully without all the duplicate dependencies that currently exist.

_benj 3y ago

I hope to find a more consistent use for guix, is just that I mostly forget about it. My default package manager (xbps) has pretty much everything I need and the rest are either so obscure that I need to patch and compile by hand or are proprietary stuff that I just run an AppImage and are done. I had a use for it sometime ago that I needed to compile Tcl, and it was a breeze to do! But outside of such niche things I haven’t found a use for guix

rgoulter 3y ago
Coming from Nix (guix's more popular, but less freedom-focused cousin).. I think part of what makes Nix "next generation" is that its functionality allows for more powerful use than "install/upgrade/uninstall package". It's neat to be able to use some program without having to install/uninstall it. I find it useful to be able to programmatically declare a set of packages (& lock their versions) that I want available when working on a project.
- f1refly 3y ago
  guix allows the user to do those things as well. Ephemeral shells with packages made available and specific environment declarations as a file are both documented and mature.
  - piperswe 3y ago
    They seem to have been pointing at Nix since they're more familiar, but acknowledging that Guix is similar in most regards. ("guix's more popular, but less freedom-focused cousin")
- herewulf 3y ago
  Look at `guix shell` and manifest.scm. `guix shell --container` is also very useful.
georgyo 3y ago
Guix is very focused on "free" software and as such is very limiting. IE, if you want to use Discord, Slack, or Steam on guix you're going to have to figure that out yourself. Nix makes this much easier and you're much more likely to find ready made packages for even esoteric software. Nix has over 3 times as much software as Guix. Nix also goes for a lot more composability than guix with nix flakes. It makes it nearly trivial to package any software you want. You may want to give Nix a try if you had trouble with Guix.

0x69420 3y ago

i find myself conflicted: - on the one hand you have the general warm fuzzy feelings associated with a considerately-designed graphical tool to lower a barrier to entry - and the fact that this tool was as trivial to implement as a cursory glance at the repo suggests vindicates the whole guix/nix declarative packaging idea. the ease with which ten lines in a text editor turned a new piece of software into a first-class citizen on my system was the thing that hooked me on nix forever but that's just it: is this really lowering the barrier to entry all that much? the audience guixsd/nixos is courting is someone sick and tired of managing config files strewn across the filesystem. by definition that is someone who knows how to operate a text editor, at which point "look at how few keystrokes/memorised file paths you need on our system vs debian/arch/whatever to gain the same thing" feels like enough of a sales pitch in terms of attention economy, this is like going "what costs you a dollar on debian costs you a dime here... hey check this out now it's 9 cents if you want. neat, huh?"

Guvante 3y ago
Writing your first one can be brutal. While using pre-existing packages can be super easy the syntax to make a package is not.
James_K 3y ago
I can see myself using this even though I know how to do most of this stuff. I don't have the exact syntax of a package memorised and I think this is probably the easiest way to write one. It doesn't have to be revolutionary, just convenient.

linschn 3y ago

Slight OT, but while we are on the monthly guix topic here, let me shamelessly plug https://the-dam.org/ https://the-dam.org/, a public-access server running GNU Guix. It will let you try it out, and chat with other individuals who are also curious about guix. An update is coming "soon" where you'll be able to mount 9P2000.L servers from guix containers, something that is currently impossible due to Linux mount namespaces not allowing anything but basically fuse. You'll be able to try all the new packages you'll create with the GUI tool from TFA.

deleted 3y ago
[deleted]
yjftsjthsd-h 3y ago
> An update is coming "soon" where you'll be able to mount 9P2000.L servers from guix containers, something that is currently impossible due to Linux mount namespaces not allowing anything but basically fuse. Isn't there a 9P FUSE client to bridge the gap?

aidenn0 3y ago

I don't use Guix, but I do use Nix, and packaging is by far the easiest thing to write in it (perhaps but surprisingly). OS modules, environments, and dev-shells are all where I would like some help...