Initial scaffolding for a standard library to develop nix-buffer functionality.

Perhaps will be by default passed to emacsBufferSetups in nixpkgs.

A (few) fully fledged examples of what one can achieve with this would be very helpful.

As far as I understand this looks for a dir-locals.nix somewhere in the directory path (to either the default directory or the current buffer's file's directory) and runs nix-build on it to generate a elisp file which is then loaded. Ignoring the safety considerations in above description, of course.

What do you use it for? Do you have examples of useful dir-locals.nix?

Thanks for this project. I appreciate it is an older piece of work, but seems to be the still only solution to load up an arbitrary nix file for a buffer? (direnv and envrc seem to be less suited)

I'm on Emacs 29. When I attempt to load in an env using nix-buffer, I get some errors that seem to break emacs to the point I'm struggling to pull up a stack trace.

Wrong number of arguments: (lambda (orig name) (if (and nixpkgs--is-nixpkgs-buffer (eq (aref name 0) 32)) (let ((buf (funcall orig name))) (progn (inherit-local-inherit-child buf) (save-current-buffer (set-buffer buf) (setq nixpkgs--buffer-count (1+ nixpkgs--buffer-count)) (add-hook 'kill-buffer-hook 'nixpkgs--decrement-buffer-count nil t))) buf) (funcall orig name))), 3

I assume that refers to here:

https://github.com/NixOS/nixpkgs/blob/c4fa270c64ab900fb55aa3a710861727d7337784/pkgs/build-support/emacs/buffer.nix#L18

nixpkgs--around-generate is advice added to generate-new-buffer.
I know little about advice-add, but I assume maybe it tries to call the advice function with the args to the original?
It seems generate-new-buffer had a new optional argument added in Emacs 28:
https://github.com/emacs-mirror/emacs/blob/7b30e11b2ac5cd360db7ee8b6aed07bd918b93a2/etc/NEWS.28#L3360

That was two years ago, but it seems nixpkgs' buffer.nix hasn't really been maintained since 2018.

Emacs versions:

GNU Emacs     v29.0.92         emacs-29.0.92
Doom core     v3.0.0-pre       HEAD -> master 24601b30 2023-08-07 20:34:53 +0200
Doom modules  v23.03.0-pre     HEAD -> master 24601b30 2023-08-07 20:34:53 +0200

With nix-shell, all the transitive dependencies have their shell hooks run. However, with nix-buffer, only top-level dependencies affect the Emacs buffer.

For example,

NIXPKGS_ALLOW_UNFREE=1 nix-shell -p coqPackages_8_16.coq coqPackages_8_16.compcert coqPackages_8_16.HoTT --run env | grep COQPATH

outputs

COQPATH=/nix/store/y46y9afvp5knxf40jyv3np8jj1sq5r2f-coq8.16-flocq-4.1.3/lib/coq/8.16/user-contrib/:/nix/store/3lgd8ca1zsbnbdxicl714fdr8h0f70zl-coq8.16-compcert-3.13-lib/lib/coq/8.16/user-contrib/:/nix/store/rw8n88pnq598daicg8k0wwc42fv8jga0-coq8.16-HoTT-8.16/lib/coq/8.16/user-contrib/

but with this dir-locals.nix

let pkgs = import <nixpkgs> { config.allowUnfree = true; };
in pkgs.nixBufferBuilders.withPackages
(with pkgs.coqPackages_8_16; [ coq compcert HoTT ])

running (nix-buffer), waiting for the derivation to compile, and then (getenv "COQPATH") gives
:/nix/store/rw8n88pnq598daicg8k0wwc42fv8jga0-coq8.16-HoTT-8.16/lib/coq/8.16/user-contrib.

This happens because compcert.lib is a dependency of compcert.out, but isn't directly in the list passed to withPackages.

I realize that this issue is with the upstream nixBufferBuilders code in nixpkgs, but I feel like it might be easier for a fix to be upstreamed if I post the issue here instead of on the nixpkgs issue tracker.

pop-to-buffer steals keyboard focus, which is very disruptive (especially as a nix novice who needs many iterations on my .nix files to get anything working). Can error messages be displayed with display-buffer instead? Or if they're short, just use message? (all the error messages I've been getting have been one-liners, although I'd prefer to have nix-buffer pass --show-trace to nix-build to get more details. I don't understand why this isn't the default).

I'm also getting uninterpreted ansi escape codes in the error buffer. I'm not sure whether this is the fault of nix-buffer or nix-build (I'm using nix 2.0, FWIW), but it would be good to either run this through the comint ansi filter or convince nix-build that it's running in a dumb terminal without color support. (This is especially annoying because the escape codes are confusing ffap)

Write the code that will become the project-specific aspects of nix-buffer flake support for a C++ + cmake based project.

There doesn't seem to be much changes on this package anymore. Is anyone still using it or did everyone migrated to something different (what?)?

Hi,

Sorry for spamming your issue tracker but I have another idea for something that could be useful.

Basically "withPackages" is equivalent to "nix-shell -p" so it would be nice to have a "withDerivation" function. This would pull in all of the build inputs for the Nix derivation and set it up like running 'nix-shell -A' would.

Currently the list of trusted expressions grows indefinitely, and we keep gc roots to the latest build for every file we ever nix-buffer into. This can be manually cleaned up by nuking the state dir and clearing nix-buffer--trusted-exprs, but this should have a cleaner interface that can be automated.

I have an old note suggesting that nix-buffer won't work via TRAMP, should confirm this and either fix it or at least signpost it well.

Right now, I don't think there is a way to get nix-buffer to work without a separate dir-locals.nix. It seems like there should be a way to set it up entirely through the `file local variables'.

For instance, I have a Haskell file that doesn't have any Stack/Cabal/etc. dependencies associate with it. Is there a way I can include dependencies in it?

I basically want to setup something like this:

-- Local Variables:
-- nix-buffer-script: "with import <nixpkgs> {}; nixBufferBuilders.withPackages [
--   haskellPackages.ghcWithPackages (pkgs: with pkgs; [ random QuickCheck parsec ])
-- ]"
-- eval: (and (require 'nix-buffer nil t) (nix-buffer))
-- End:

and have it work out of the box. Is that seem reasonable? This is just me brainstorming how to do this right now.

Lots of Nix projects already have a "default.nix" file with one derivation. Can the inputs of that be used to automatically setup nix-buffer without the dir-locals.nix?

/cc @shlevy

I'm not sure if I'm using this correctly. But my project is set up like this:

project-dir
|__dir-locals.nix
|__python
   |__program.py

My dir-locals.nix contains the following:

let pkgs = import <nixpkgs> {}; in
  pkgs.nixBufferBuilders.withPackages [
    pkgs.python3
    pkgs.python36Packages.uproot
    pkgs.python36Packages.tensorflow
    pkgs.python36Packages.matplotlib
    pkgs.python36Packages.numpy
    pkgs.python36Packages.pandas
    pkgs.python36Packages.scipy
    pkgs.python36Packages.Keras
  ]

So with this setup, I first open program.py in emacs and then run nix-buffer. The first time I did it, it even asked me whether to trust the generated elisp code. I hit y but nothing happened after that. Flycheck still complains about not being able to find the python libraries. Now, when I run nix-buffer, it doesn't even ask me if I trust the elisp code anymore (I guess because it remembered that).

Did I do anything wrong or is this a bug?

Currently the nix-buffer code in nixpkgs has very shaky support for detecting "child" buffers, and comint in particular is painful. We should have a better reusable version of this in some standard library.

Current description and title written by @shlevy

Original description and title from @matthewbauer :

"compile" buffer doesn't inherit PATH or exec-path

This is a weird issue because I expected this to work.

Basically, running "compile" with something on nix-buffer's path will not be found for whatever reason. I think it is an issue with inheriting process-environment and exec-path.

Need new repos to contain the defaults for the non-project-specific configuration of flake mode (how the project flake is consumed, how the evaluation is configured).

Currently, if you have a failing nix-build result, nix-buffer will continually try to run (when used as a find-file-hook). We should try to "mark" these failing builds once and avoid rebuilding until the inputs change.

To pass a different buffer-file-name to each build, we'll need different generated flakes per file, but we want dependency versions to be shared by all buffers for a given project. I think there's some way to have a common flake registry that would support this, I should confirm and understand how it would work.

I think this is because I am on emacs 24. I will report back when I have upgraded.