David Thompson <dthomps...@worcester.edu> skribis: > Okay, so after digging into nix's source code a bit, I've learned a few > things. nix-shell is really just a symlink to nix-build, and it doesn't > seem to use profiles at all! When nix-build is called as 'nix-shell', > it's behavior changes. From the manual: "The command nix-shell will > build the dependencies of the specified derivation, but not the > derivation itself."
Ooh, OK. Interesting. > I can see that the nix-build script exits before adding the derivation > to the store when called as 'nix-shell'. > > Here's the relevant Perl source code: [...] > (Thank you for choosing Scheme, btw) Yup. :-) > I found it confusing to have the build script also handle the shell via > some conditional logic. I think Guix could do it better. +1 > I will implement 'guix shell' if I can get your opinion on the best > approach to take. Would you tweak guix/scripts/build.scm to handle > the special case or export the necessary procedures and create a > guix/scripts/shell.scm module? The problem with a command that spawns a shell IMO is that it does not compose well: you get a new shell (which shell program is actually run?), and you can influence a running shell, or use it in a script, etc. So instead I would imagine a command like: guix environment emacs which would build the dependencies of Emacs, and then output the search path as per ‘guix package --search-paths’, so that one can just source it and be done. In addition, one could do things like: guix environment -l foo.scm Things like that. WDYT? Thanks, Ludo’.
