Warning about interpretation of store path arguments should be removed by now

emilazy commented

2025-07-02 17:59:16 +00:00

Member

This warning was added in Nix 2.15 in 2023, so the behaviour has been consistent throughout Lix’s existence. Nix 2.24.11 removed the warning half a year ago. I run into this daily and it’s quite annoying; I think it could safely be dropped. (Even if the interpretation of installables might change in the future, this warning doesn’t do anything to prepare anyone for that.)

emilazy added the

ux

label

2025-07-02 17:59:16 +00:00

emilazy changed title from ~~warning: The interpretation of store paths arguments ending in .drv recently changed.~~ to `warning: The interpretation of store paths arguments ending in .drv recently changed.`

2025-07-02 18:00:55 +00:00

emilazy changed title from ~~`warning: The interpretation of store paths arguments ending in .drv recently changed.`~~ to ` warning: The interpretation of store paths arguments ending in .drv recently changed. `

2025-07-02 18:01:10 +00:00

emilazy commented

2025-07-02 18:01:22 +00:00

Author

Member

Uh, I give up on the title :)

👍 1

raito changed title from ~~` warning: The interpretation of store paths arguments ending in .drv recently changed. `~~ to Warning about interpretation of store path arguments should be removed by now

2025-07-02 18:06:03 +00:00

jade commented

2025-07-02 23:49:22 +00:00

Owner

I have a CL to reword it somewhere. It needs more work before merge because it's still true that putting a .drv path into nix build is basically always wrong and so we do want a hint for that.

emilazy commented

2025-07-03 00:13:10 +00:00

Author

Member

“Basically always wrong” is too strong. It is useful to substitute a .drv from a binary cache. “nix build ‹store path› tries to make ‹store path› exist” might be initially unintuitive, but it is a pretty simple and orthogonal interface, and I would find it unfortunate to have warnings for commands that are behaving uniformly and are sometimes useful. I suspect that it is much more confusing to users used to nix-build than it is to new users, who are unlikely to be passing .drv paths directly into commands anyway.

In any case, it comes up when doing things like nix copy --to ssh-ng://remote-machine /nix/store/foo.drv, which absolutely should not have a warning. If it was just nix build, I wouldn’t mind as much, but I still don’t think it’s a good idea.

“Basically always wrong” is too strong. It is useful to substitute a `.drv` from a binary cache. “`nix build ‹store path›` tries to make `‹store path›` exist” might be initially unintuitive, but it is a pretty simple and orthogonal interface, and I would find it unfortunate to have warnings for commands that are behaving uniformly and are sometimes useful. I suspect that it is much more confusing to users used to `nix-build` than it is to new users, who are unlikely to be passing `.drv` paths directly into commands anyway. In any case, it comes up when doing things like `nix copy --to ssh-ng://remote-machine /nix/store/foo.drv`, which absolutely should not have a warning. If it was just `nix build`, I wouldn’t mind as much, but I still don’t think it’s a good idea.

jade commented

2025-07-03 01:19:39 +00:00

Owner

This is true. I still think it's surprising to not have a hint to teach people about the output syntax though. I think a big part of why it's confusing is that usually nix build means to build something when using normal installables but then when using store path installables it pretty much means realise from binary cache.

I don't think the design is bad! But it leaves an opportunity to put a hint. We would really benefit from better config handling so we could have hints you can disable easily, which then would largely resolve any complaints about it being annoying i think.

This is true. I still think it's surprising to not have a hint to teach people about the output syntax though. I think a big part of why it's confusing is that usually nix build means to build something when using normal installables but then when using store path installables it pretty much means realise from binary cache. I don't think the design is bad! But it leaves an opportunity to put a hint. We would really benefit from better config handling so we could have hints you can disable easily, which then would largely resolve any complaints about it being annoying i think.

emilazy commented

2025-07-03 01:35:23 +00:00

Author

Member

I guess I don’t find it that weird, because you can treat nixpkgs#hello as being short for the result of nix eval nixpkgs#hello.outPath – the same as you’d get from "${pkgs.hello}" – and then the behaviour is the same (try to substitute the given path, otherwise try to build it if possible). So my mental model of installables is that they are notation for things that eventually reduce to store paths. Though I guess this is actually incomplete and you have to interpret it as being the drvPath followed by ^…` for the command to know how to build it…

(I do sometimes get it wrong, and the ^* syntax is kind of funky, and the less said about the strange use of flags as part of installable syntax the better. But I wouldn’t call it one of the confusing parts of Nix’s interface for me personally; I actually find it quite a bit easier to predict than the old CLI.)

If there’s any indication that new users try passing .drv paths and get confused, then an opt‐out hint seems justifiable. In the meantime though, it’s super annoying for nix copy, and I haven’t personally seen confusion about this since Nix dropped the warning, so maybe it’d be best to just drop it for now and revisit as part of a more general assessment of new user pitfalls that could use hints if a system like that is added?

I guess I don’t find it that weird, because you can treat `nixpkgs#hello` as being short for the result of `nix eval nixpkgs#hello.outPath` – the same as you’d get from `"${pkgs.hello}"` – and then the behaviour is the same (try to substitute the given path, otherwise try to build it if possible). So my mental model of installables is that they are notation for things that eventually reduce to store paths. Though I guess this is actually incomplete and you have to interpret it as being the `drvPath followed by `^…` for the command to know how to build it… (I do sometimes get it wrong, and the `^*` syntax is kind of funky, and the less said about the strange use of flags as part of installable syntax the better. But I wouldn’t call it one of the confusing parts of Nix’s interface for me personally; I actually find it quite a bit easier to predict than the old CLI.) If there’s any indication that new users try passing `.drv` paths and get confused, then an opt‐out hint seems justifiable. In the meantime though, it’s super annoying for `nix copy`, and I haven’t personally seen confusion about this since Nix dropped the warning, so maybe it’d be best to just drop it for now and revisit as part of a more general assessment of new user pitfalls that could use hints if a system like that is added?

jade commented

2025-07-03 02:48:57 +00:00

Owner

That sounds reasonable to me. We should make a tracking issue about the broader capability to do git/jj-like hints, and then we can just remove this warning with a thought to add it back later in a more limited form.

jade referenced this issue

2025-07-03 02:51:56 +00:00

ux: support optional hints #898

lix-bot commented

2025-07-06 15:20:30 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/3590 ("libcmd: drop warning about interpretation of store paths")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/3590](https://gerrit.lix.systems/c/lix/+/3590) ("libcmd: drop warning about interpretation of store paths")

lix-project referenced this issue from a commit

2025-07-07 23:13:51 +00:00

libcmd: drop warning about interpretation of store paths

lix-project closed this issue

2025-07-07 23:13:51 +00:00

Rows
Columns

Warning about interpretation of store path arguments should be removed by now #897