The plan is to remove nix-* eventually and flakes commands are not really different to the old commands. Flakes are mostly the flake reference and new subcommands which where not available before.
nix profile --delete?
Ideally generations wouldn’t have any date associated to them to be fully reproducible.
That is already a thing. They are just called nix3-build instead of nix-build.
It is really hard to find a consensus on this. There are even voted to remove the registry and remove the silent defaults.
nix diff-closure already does that but it could be improved with an alias to make it simpler to use.
Could be an alias like nix fmt but without a rewrite and cleanup of the shell code I don’t see to much of an benefit.
It only fixes up the flake.lock if it does not match the inputs. Removing this would decrease UX.
Yes, definitely.
Isn’t the workflow that you reboot into the old generation?
nix3-flake for now. Will probably be fixed when nix-command leaves the experimental phase. This is necessary to not replace old command man pages.
You can also specify .#package. Displaying the last failed build could work for simple cases but when multiple packages fail this would be ambiguous.
I tried to achieve that or an nixosConfiguration earlier with builtins and lib functions, but failed. Since toJSON cannot handle functions inside a Set. Replacing them with dummy strings did not work either, since mapAttrsRecursive seemingly does not recurse deep enough to catch all.
That was not my complaint. The nix command implements new CLIs for both flakes and non-flakes, but they’re unified in a problematic way IMO. As I said, nix build .#foo and nix build -f . foo is an example where the CLI is unified but the behavior is significantly different.
There’s no date in the actual store object, of course, but the system profile symlinks have a timestamp. nix-collect-garbage already implements --delete-older-than using these timestamps. I just want to be able to combine the already available criteria in a more useful way. There’s nothing wrong with that from a reproducibility perspective in my view. Are you saying that’s a reproducibility problem?
AFAIK this is the last remaining nix profile CMD required to advise people “never use nix-env if you have migrated to flakes”. Having to tell coworkers “never use nix-env except to switch profiles” always feels icky and inevitably leads to a history lesson.
One annoyance is that nix run and nix bundle have no way of specifying an alternate binary when using a derivation, and it’s not clear how to from their manual pages. For example, if you want to run qalc from nixpkgs#qalculate, then I don’t think there’s a way using nix run (since nix run nixpkgs#qlalculate qalc tries to run /bin/qalculate with the argument qalc), and instead you need nix shell nixpkgs#qalculate -c qalc. Similarly, with nix bundle, if you only have a derivation and not an app, there’s no way to specify an alternate binary to use as the one that gets run when the bundle gets run. As far as I can tell, there’s not really a workaround for this.
Actually this is in the nix3-run man page explaining the sequence of how it determines what to run if the target is not an app:
• The meta.mainProgram attribute of the derivation.
• The pname attribute of the derivation.
• The name part of the value of the name attribute of the derivation.
So you can add a meta.mainProgram = "qalc" for you example.
That’s great and all but A. that hasn’t happened for every package yet and B. there are packages with multiple executables in them you might want to use. I.e. ffmpeg and ffprobe are both in ffmpeg. Obviously you’d expect it to run ffmpeg by default and that makes sense but what if you wanted to run ffprobe instead?
I see no reason not to offer the user a choice which binary they wish to run. I’d see that as an integral part of the run subcommand. Something like nix run nixpkgs#ffmpeg ffprobe -i /path/to/file.mp4 should just work.
Yeah makes sense, the workaround given is pretty ugly too. It does seem a little weird that nix run and nix shell -c do almost the same thing, where the latter is just more explicit.
I left a comment on a recent PR of my mine and I’d like to drop a quote from it since it seems relavent to the overall point of this thread:
we may want to consider a more “plumbing” and “porceline” approach for flakes 2.0, to keep drift between the old and new commands from becoming a big issue.
I like the low-level control the legacy commands give me when I need that. Say in a complex CI system that focuses on doing as little work as possible, but I like the higher level commands for ease of use when working on my own system. I think there is an argument to be made for keeping both around and taking implementations from the lower-level commands and reusing them for their flake counterparts.
Perhaps I am missing something, but a more “git-like” approach may be the key to refining the UX in the future without sacrificing power where required.
the /bin/sh -c wrapping should be used if you need to run a real shell command like ffprobe -i something && ffmpeg something else && whatever, which used to work with nix-shell but not with nix shell
