Allow setting nested attributes via `--arg`/`--argstr`

ma27 commented

2024-09-01 16:03:13 +00:00

Member

Yes, nix-build -A foo --arg config '{allowAliases=true;}' is quite annoying to type out.

Describe the solution you'd like

I intuitively assume that I can do nix-build --arg config.allowAliases true and then realize that this isn't the case. Would be kinda neat if this would be possible.

Describe alternatives you've considered

The nixpkgs config arguments are pretty nixpkgs-specific. I briefly considered allowing via CLI to do stuff such as allowAliases/allowUnfree/..., but couldn't think of a reasonable way.

My proposal isn't the prettiest either, but makes the usability notably better, in my opinion at least.

If somebody has a better idea for that problem I'd be happy to discuss. If people agree on that, I'd give this a shot soonish.

Additional context

What needs to be discussed is how we want to do set merging then. I could think of:

doing the exact same thing Nix does in its language. I.e. --arg config '{ ... }' --arg config.foo '...' works. So does rec config {}.
only allow non-conflicting declarations, i.e. if --arg config.foo.bar is set, one/few must not specify --arg config or --arg config.foo. This is a CLI and not Nixlang after all.

## Is your feature request related to a problem? Please describe. Yes, `nix-build -A foo --arg config '{allowAliases=true;}'` is quite annoying to type out. ## Describe the solution you'd like I intuitively assume that I can do `nix-build --arg config.allowAliases true` and then realize that this isn't the case. Would be kinda neat if this would be possible. ## Describe alternatives you've considered The nixpkgs `config` arguments are pretty `nixpkgs`-specific. I briefly considered allowing via CLI to do stuff such as `allowAliases`/`allowUnfree`/..., but couldn't think of a reasonable way. My proposal isn't the prettiest either, but makes the usability notably better, in my opinion at least. If somebody has a better idea for that problem I'd be happy to discuss. If people agree on that, I'd give this a shot soonish. ## Additional context What needs to be discussed is how we want to do set merging then. I could think of: * doing the exact same thing Nix does in its language. I.e. `--arg config '{ ... }' --arg config.foo '...'` works. So does `rec config {}`. * only allow non-conflicting declarations, i.e. if `--arg config.foo.bar` is set, one/few must not specify `--arg config` or `--arg config.foo`. This is a CLI and not Nixlang after all.

jade commented

2024-09-01 17:50:28 +00:00

Owner

This might be a regression to fix since it would break users who are setting an arg that has dots in it.

jade added the

ux

label 2024-09-01 17:50:40 +00:00

ma27 commented

2024-09-01 18:56:36 +00:00

Author

Member

Good point!

The first question is if you think it's worth making the change, but with a deprecation period (i.e. Lix 2.92 will give a warning when using dots in --arg, 2.93 may error out, then the change). Alternatively, we could add another CLI arg for that, but that may be even more confusing. I can't remember having seen --arg with dotted attribute names anywhere whereas the --arg config.X is a thing for nixpkgs, so doing that might be an option, IMHO at least.

With that said, we'd want to interpret CLI args as identifiers then, correct (assuming we want to explore that further)? I.e. you can still specify dotted args by --arg '"foo.bar"', same for all other things that cannot be part of an identifier, right?

Good point! The first question is if you think it's worth making the change, but with a deprecation period (i.e. Lix 2.92 will give a warning when using dots in `--arg`, 2.93 may error out, then the change). Alternatively, we could add another CLI arg for that, but that may be even more confusing. I can't remember having seen `--arg` with dotted attribute names anywhere whereas the `--arg config.X` is a thing for nixpkgs, so doing that might be an option, IMHO at least. With that said, we'd want to interpret CLI args as identifiers then, correct (assuming we want to explore that further)? I.e. you can still specify dotted args by `--arg '"foo.bar"'`, same for all other things that cannot be part of an identifier, right?

jade commented

2024-09-09 03:32:55 +00:00

Owner

yyyyyyeah, I really don't like interpreting things as identifiers in the CLI. it makes scripts have to think about what an identifier is to Nix and escape it properly, whereas if it's passed straight-through as a string, they don't have to worry about any such thing.

Whether this is a big deal for --arg is another question; I don't know how many instances there are of people putting non-identifiers into there because who the heck puts illegal identifiers into function args? I would be fine if we emitted a warning if the --arg value was an illegal identifier, linking to this issue and asking for people to report their use case, then we could probably find out if this is going to break anyone before actually breaking them. Then in a future version we could turn it into an identifier.

But accepting identifiers in here feels kind of sketchy, and we would have to think about how the merging rules would work for multiple --arg config.foo (not trivial; consider --arg config.foo.bar 2 and --arg config.foo '{meow = 4;}').

yyyyyyeah, I really don't like interpreting things as identifiers in the CLI. it makes scripts have to think about what an identifier is to Nix and escape it properly, whereas if it's passed straight-through as a string, they don't have to worry about any such thing. Whether this is a big deal for `--arg` is another question; I don't know how many instances there are of people putting non-identifiers into there because who the heck puts illegal identifiers into function args? I would be fine if we emitted a warning if the --arg value was an illegal identifier, linking to this issue and asking for people to report their use case, then we could probably find out if this is going to break anyone before actually breaking them. Then in a future version we could turn it into an identifier. But accepting identifiers in here feels kind of sketchy, and we would have to think about how the merging rules would work for multiple `--arg config.foo` (not trivial; consider `--arg config.foo.bar 2` and `--arg config.foo '{meow = 4;}'`).

ma27 commented

2024-09-09 13:53:19 +00:00

Author

Member

I would be fine if we emitted a warning if the --arg value was an illegal identifier, linking to this issue and asking for people to report their use case, then we could probably find out if this is going to break anyone before actually breaking them

Yeah, that's even better than starting a deprecation right now, agreed!

But accepting identifiers in here feels kind of sketchy, and we would have to think about how the merging rules would work for multiple --arg config.foo

So my two suggestions are flat out prohibiting that or copying the behavior of the Nix language (i.e. --arg config.foo "{ ... }" can be merged with any --arg config.foo.X, including all the weirdness such as #329).

My gut feeling prefers the former.

wdyt?

> I would be fine if we emitted a warning if the --arg value was an illegal identifier, linking to this issue and asking for people to report their use case, then we could probably find out if this is going to break anyone before actually breaking them Yeah, that's even better than starting a deprecation right now, agreed! > But accepting identifiers in here feels kind of sketchy, and we would have to think about how the merging rules would work for multiple --arg config.foo So my two suggestions are flat out prohibiting that or copying the behavior of the Nix language (i.e. `--arg config.foo "{ ... }"` can be merged with any `--arg config.foo.X`, including all the weirdness such as #329). My gut feeling prefers the former. wdyt?

jade commented

2024-09-10 00:18:23 +00:00

Owner

Yeah I am inclined to want to be more strict, since you can be looser later on. I think @piegames would thank us for doing that, if we take such an approach, since they have been deep in knowing too much of the merging rules.

piegames commented

2024-09-10 07:05:35 +00:00

Member

I am nothing but the right arm of @pennae, who is also the primary source of my knowledge. I haven't fallen down the rabbit hole of attribute merging yet (it's on my TODO list though), but AFAIK the issues with merging come up with recursive attrsets and other interactions with language features. Moreover, attrset merging is merely syntactic sugar within the parser, so outside of that one has to explicitly define some semantics anyways.

ma27 self-assigned this 2024-09-15 14:53:07 +00:00

lix-bot commented

2024-09-15 14:59:16 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/1918 ("common-eval-args: raise warning if --arg isn't a valid Nix identifier")
comment in cl/1918 ("common-eval-args: raise warning if --arg isn't a valid Nix identifier")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1918](https://gerrit.lix.systems/c/lix/+/1918) ("common-eval-args: raise warning if `--arg` isn't a valid Nix identifier") * comment in [cl/1918](https://gerrit.lix.systems/c/lix/+/1918) ("common-eval-args: raise warning if `--arg` isn't a valid Nix identifier")

lix-project referenced this issue from a commit

2024-09-16 12:49:19 +00:00

common-eval-args: raise warning if `--arg` isn't a valid Nix identifier

Allow setting nested attributes via --arg/--argstr #496

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Allow setting nested attributes via `--arg`/`--argstr` #496