Hacking anything with GNU Guix

307 点作者 podiki超过 2 年前

15 条评论

podiki超过 2 年前

Another great use of guix shell that I tend to do is for one off commands. I don't need OBS installed to use it occasionally, I can just do "guix shell obs -- obs" to run it once and not have it in my PATH, application launcher, etc. when I don't need it. Or better yet for running python or CL scripts, with something like 'guix shell python [python packages] -- python3 myscript.py "some argument"'. No need to carry around these libraries. This can be done with a manifest or guix.scm file as well, that guix shell will use automatically (once authorized, so you don't accidentally run something).This keeps things tidy in terms of just having packages I need all the time installed, while still being very quick after the first run. (There are some caveats about garbage collection, but I rarely do that.)And as the article mentioned there's also containers...lots of useful tools.

davexunit超过 2 年前

'guix shell' is killer. I use it for all my projects and one-off experiments. I also hook it up to Emacs 'M-x compile' so that compilation happens in the context of the guix shell. Beyond the simple command line package specification, you can add a guix.scm file to the root of your project repo and fill it with code that specifies all the packages needed for a development environment. Some of my guix.scm files are simple lists of existing packages, others are full of custom code to modify existing packages or define new ones. No matter how simple or complex it is behind the scenes, I just run 'guix shell' and get on with working on my project.

评论 #32930410 未加载

评论 #32935117 未加载

评论 #32931239 未加载

bogwog超过 2 年前

I had an idea recently to try out Fedora silverblue with Guix on top.Silverblue gives you an immutable root filesystem, which is great for building a reliable and reproducible system, but it makes installing software more complicated. Containers are the main solution, and stuff like flatpaks and toolbox. That (mostly) works, but it’s a bit heavy handed and not without annoyances.But with guix, your packages live in the guix store, and don’t touch your os packages. So that seems like a good way to manage software on top of an immutable OS.Unfortunately when I went to try it out, I learned that the only way to change the default location of the guix store (since /gnu/store won’t work in silverblue, and Guix isn’t available as a package for fedora) is to build it from source... and then I ran into some build issues when trying to do that and gave up....So maybe someone less lazy than I will pull it off and report back whether it’s actually a good idea or not!

评论 #32928088 未加载

评论 #32928357 未加载

评论 #32928065 未加载

评论 #32927737 未加载

评论 #32927930 未加载

评论 #32930119 未加载

评论 #32935126 未加载

retzkek超过 2 年前

It should be pointed out that "guix shell" is currently only available in the unstable "latest" version, not the stable "standard" release (v1.3.0). If you are running an older version, "guix environment" is similar.<a href="https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html" rel="nofollow">https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...</a><a href="https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-environment.html#Invoking-guix-environment" rel="nofollow">https://guix.gnu.org/en/manual/en/html_node/Invoking-guix-en...</a>

评论 #32934732 未加载

rank0超过 2 年前

Can anyone explain to me the appeal of guix over nix? Is the learning curve any easier? I really badly wanted to like nix...but its just so strange and unconventional.Whenever I need a disposable environment I reach for lxc/lxd.

评论 #32927900 未加载

评论 #32927809 未加载

评论 #32928503 未加载

评论 #32927591 未加载

评论 #32928160 未加载

评论 #32927599 未加载

评论 #32932951 未加载

评论 #32927579 未加载

genpfault超过 2 年前

...except KDE[1]:> GNOME, Xfce, LXDE, and Enlightenment are available (see Desktop Services), as well as a number of X11 window managers. However, KDE is currently missing.[1]: <a href="https://guix.gnu.org/manual/en/html_node/Limitations.html" rel="nofollow">https://guix.gnu.org/manual/en/html_node/Limitations.html</a>

kqbx超过 2 年前

> PYTHONPATH, CPATH, etc are all set up and ready to go.Does that mean that Guix just exports the required environment variables in the shell rather than wrapping each executable with a bash script [1] like nix does?If yes, that's great, because the wrapper approach feels like an ugly hack. I found some executables on my nixos installation that are behind three layers of wrappers, and that's probably not the maximum.I guess nix could improve this situation by making `wrapProgram` smarter (if the executable to be wrapped is already a wrapper, merge the inner and outer wrapper), but even single-layer wrappers are annoying, and I imagine they have some performance impact.EDIT:I forgot about nix-shell, which does actually export the right environment variables directly to the shell.[1] <a href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-wrapper.sh" rel="nofollow">https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp...</a>

评论 #32931550 未加载

评论 #32930957 未加载

zelphirkalt超过 2 年前

Plus: You can make it all reproducible using `guix time-machine`.

pmarreck超过 2 年前

It seems so obvious to me now that the fundamental design decision in Nix/Guix (to encapsulate dependencies via a content-addressed store, to make only those specific dependencies visible to the dependent app or library, to express all of this declaratively somehow, and to basically treat the entire build process and in fact the entire system configuration like a pure function with a deterministic result) is the way forward.

chubot超过 2 年前

I had a couple people attempt this for the dev environment of <a href="https://www.oilshell.org/" rel="nofollow">https://www.oilshell.org/</a> with Nix, and it wasn't entirely successful. (Not Guix, but my understanding is that Guix would have the same issues)As background, we've long had a set of evolving shell scripts that fetch and build dependencies at specific versions -- like bash/dash/zsh/mksh/busybox to test against, re2c to generate code, CommonMark, Python 3.10, MyPy with pip dependencies, and (bonus) R with CRAN dependencies.I wrote about 2 problems here: <a href="https://lobste.rs/s/s5co2f/where_contributors_have_problems_with#c_ndbezz" rel="nofollow">https://lobste.rs/s/s5co2f/where_contributors_have_problems_...</a>1. OS X and libc, which is not really a problem since our existing scripts don't solve it either. It was just one motivation for Nix that didn't quite work out.2. The file system layout becomes different, and Oil's shell tests rely on that. So containers ended up being easier. The whole build and test system runs in OCI containers under Docker and podman now, so it's pretty reproducible and automated.But I still think it would be nice if someone who actually knows Nix and Guix (unlike me) tries again. The dependencies are more stable now than 2 years ago.I think you have to write like 10 Nix or Guix expressions from scratch with the exact tarballs that we use. (Otherwise the tests will break even more, because Oil's tests are extremely detailed and find bugs in specific versions of specific shells.)Right now we have a 134 line shell.nix that tries to reuse Oil's scripts, but I think it doesn't gibe with the way that Nix and Guix are meant to be used. Probably the real solution would be more like 1000 lines from scratch?I remember that Nix Flakes was what I thought Nix was going to be, but at the time it wasn't ready. I thought Nix was supposed to solve the "it works on my machine" problem but it actually doesn't -- you still need a CI because it's possible to write .nix expressions in ways that break the sandboxing (unlike Bazel where you always get it).I had ran this by someone who knows Guix and my takeaway was that Guix is basically the same in that regard.A key problem is that, at least for awhile, I want it to work in parallel with our existing system ... not have a "big break".

评论 #32931388 未加载

评论 #32927860 未加载

评论 #32928336 未加载

data_maan超过 2 年前

I'm not extremely competent in low-level SW engineering, so would anyone be willing to enlighten how all these shells and environment isolation techniques work?Even Python's virtual environment mechanisms are opaque to me and guix seems to be able to basically do that - but for anything you can think of (?).

评论 #32935445 未加载

评论 #32935552 未加载

pizza超过 2 年前

The article is about having the correct environment set up - attacking the problem from the environment level.When I think of "hacking code you didn't write" one of the biggest hurdles for me is "inserting my changes to the behavior of the code with minimal refactoring of the original" - attacking the problem from, perhaps, compiler instrumentation level.e.g. suppose when I use some library function f, there is a deeply nested function, g, that has access to some data x, which is cleaned up somewhere before the API returns its result.How do I tell my compiler "I want a new function h, which, when given the same arguments as f, returns x, by returning from within g" ?

评论 #32930029 未加载

hedora超过 2 年前

Can anyone comment on how this compares to apt-get source? (Optionally run inside docker?)

评论 #32930841 未加载

评论 #32928553 未加载

评论 #32928516 未加载

yig超过 2 年前

xmake [1] gives you something like this via `xrepo env shell`.[1] <a href="https://xrepo.xmake.io/" rel="nofollow">https://xrepo.xmake.io/</a>

jalino23超过 2 年前

thank you hn! this is a such a gem find