Pierre Neidhardt writes: > Basically inxi sets a 'paths' variable with the usual Unix paths and > then forces the environment PATH to the same value. > > My suggestion instead: set 'paths' to /run/current-system/* and > ~/.guix-profile/{sbin,bin}. > > What do you think? Is this generic enough? Is ~/.guix-profile a > guaranteed location for the user profile? No, ~/.guix-profile is not guaranteed. Users can and do create profiles in various places, e.g. with "guix package -p my-profile -i hello". In addition, /run/current-system/* would not work on foreign distros. Is inxi a program, or a library? If it's a program, then a better solution is to bind PATH to the required dependencies at build time. An easy way to accomplish that would be to use the wrap-program procedure from (guix build utils). Read its docstring and grep for wrap-program in the gnu/packages directories to see how it's used. The basic idea is that we can create a wrapper script for inxi which launches inxi in an environment where PATH is set to exactly the things it needs. There are other ways to accomplish the same thing. For example, we could replace references in the source code with references that point to precisely the things required. Generally we would add or modify a build phase to accomplish this; read the docstring for the substitute* procedure (also defined in (guix build utils) and grep for it in the gnu/packages directories to see this technique in action. Inxi has been written, like much software, to be composed with other software at runtime; the composition is normally achieved via environment variables. The techniques above allow us to compose inxi with its dependencies at build time, which is desirable because it means that the built program will behave the same on my machine as it does on yours, regardless of how my environment is configured. This is known as "static composition" of software components (see Section 7.1.1, "Principles", in the Nix thesis [1]). Footnotes: [1] https://nixos.org/~eelco/pubs/phd-thesis.pdf -- Chris