Alternative implementation of #4479

@edolstra Thoughts on this one?

@edolstra Ping.

@edolstra if there are no objections I'll merge this soon.

Please not, I'm not so happy about making it impossible to pass --option after the subcommand. That's suboptimal UX.

@edolstra It's not impossible, it's just a warning. The only option that can't be passed after the subcommand is plugin-files. We can remove the deprecation warning too.

@edolstra Can we set up some time next week to talk through next steps? Maybe Monday in the EST morning?

Is there any further read about this feature in general, about what plugins are supposed to do/access, and what not?

I'm somewhat worried exposing the somewhat in flux internal Nix API, which was never stable or formalized to plugins either will lead to not being able to change internal API (cause people are afraid to break plugins), or changes in Nix suddenly causing breakages (cause there is no contract about what's stable).

@flokli plugins predate this work, and in fact we thought command plugins already worked: https://nixos.org/manual/nix/stable/#conf-plugin-files

There is no expectation of stability around these APIs, or there shouldn't be.

This PR simply fixes when command plugins are loaded so they can take effect.

There is no expectation of stability around these APIs, or there shouldn't be.

@shlevy thanks for the clarification. The section in the manual isn't clear enough for my taste regarding stability guarantees, but that's probably out of scope for this PR.

@flokli You're right, fixed 35205e2

Thanks!

@edolstra Updated with removal of the deprecation.

Thanks!

What is the correct way to load plugins to avoid the error message?
I have tried everything I can think of, and while nix doesn't actually crash, I'm going to have to wrap the executable in something to swallow this error message because I cannot get it to go away.

warning: error: plugin-files set after plugins were loaded, you may need to move the flag before the subcommand

These all emit the warning/error ( unsure of which it actually is since it's stated as being both a warning and an error ):

nix --plugin-files "$PWD/libfoo.so" CMD ...;
nix --option plugin-files "$PWD/libfoo.so" CMD ...;
nix CMD --plugin-files "$PWD/libfoo.so" ...;
nix CMD --option plugin-files "$PWD/libfoo.so" ...;
NIX_CONFIG="plugin-files = $PWD/libfoo.so" nix CMD ...;

This one convinced me the error message was just completely bogus:

(
  export XDG_CONFIG_HOME="$( mktemp -d; )";
  cp -r -T -- "$HOME/.config/nix" "$XDG_CONFIG_HOME/nix";
  echo "plugin-files = $PWD/libfoo.so" >> "$XDG_CONFIG_HOME/nix/nix.conf";
  nix CMD ...;
);

I can file a bug report but wanted to check to make sure I wasn't just using the flags incorrectly or something.

@aakropotkin fixed in #7736

@aakropotkin Note that even without this fix nothing actually fails to work, you just get this erroneous warning message. The client does in fact load the plugin-files.

Yeah luckily the plugins still work which is the most important thing.

Out of curiosity @shlevy have you encountered crashes on exit using allocValue from plugins? I know you use them quite a bit and thought you might know how to deal with them. Notably these only seem to appear on Darwin. I'm guessing it's a static initialization issue, but haven't had time to do a deep debug session.

I've tried this block a dozen ways and always hit a syscall failure on exit : https://github.com/aakropotkin/floco/blob/54f5bf1bbff1f5d3dd81577ad258b46121aef05f/pkgs/nix-plugin/npm-wrap.cc#L138
Works fine on Linux. I've tested a minimal case and I've found that calling allocValue at all will cause the issue.
Placing the same code in primops.cc also works.

@aakropotkin I haven't, but my usage has been very sporadic, sorry.