@alios
GOAL: or Isolated , interoperable env , shells by path, w/ central config cc
envs need not be interoperaple for different langs , say cc has a "devenv.lib.mkshell" for a rust tool `x` which is a runtime dep of epkgs 'ey`for rust work
Now If I enter this devshell with nix `develop ` and do a ` cargo install x` here
path of x is
> .devenv/state/cargo-install/bin/
Do note that my PWD is not ${HOME} here.
> But if I do a cargo install x from ${HOME} , it ll be in ~/.cargo/bin
Now lets say I install a melpapackages `ey` with my dotfiles' emacs.nix "emacs overlay`
It may be
`ls ~/.emacs.d/elpa/ | grep ey.elc` iff it's byte-compiled.
ey won't find it `x` , till you explicitly add this emacs load-path or to NIX-BUFFER's default.nix list of deps /project [This is just for the projects of 1 lang , nearly any serious work has > = 2] ,
or write .envrc /per project , so no global devenv/devshell.
Not every dir need be byte compiled
Possible reasons
While -
1. Nix does follow the XDG specs, Emacs does not fully follow it for its configuration and data files.
2. NIx Does not follow FHS hierarchy, Emacs Does.
3. Nix build re reproducible.
4. Nix is content addressed , store (hashed) paths
nix-instantiate --eval-only --expr '(import <nixpkgs> {}).emacs.outPath', it could be emacs or go or cargo or whatever your need, it need not have .
Some of your emacs data can be here. But I care bout getting deps in the path
One possible way could be to write a global devshell just for my init.el and launch it from there. But it's not easily extendable , more langs' projects ll put me back to square one.
Just nix-buffer seems to unsustainable
#nix #emacs
