Provide a way to bind the argument set *including* default values #1461
Assignees
Comments
jtojnar
referenced
this issue
in NixOS/nixpkgs
Dec 29, 2019
Bash takes an assignment of a string to an array variable: local -a user_args user_args="(foo bar)" to mean appending the string to the array, not parsing the string into an array as is the case when on the same line as the declaration: local -a user_args="(foo bar)" b063340 extracted the declaration before the newly branched code block, causing string makeWrapperArgs being added to the array verbatim. Since local is function scoped, it does not matter if we move it inside each of the branches so we fix it this way.
jtojnar
added a commit
to NixOS/nixpkgs
that referenced
this issue
Dec 29, 2019
When `makeWrapperArgs` variable is not set, `declare -p makeWrapperArgs` will return with 1 and print an error message to stderr. I did not handle the non-existence case in b063340 because I thought `mk-python-derivation` will always define `makeWrapperArgs` but `wrapProgram` can be called independently. And even with `mk-python-derivation`, `makeWrappers` will not be set unless explicitly declared in the derivation because of NixOS/nix#1461. I was lead to believe that because the builds were succeeding and I confirmed that the mechanism fails when the variable is not defined and `-o nounset` is enabled. It appears that `wrapPython` setup hook is not running under `-o nounset`, though, invaldating the assumption. Now we are checking that the variable exists before checking its type, which will get rid of the warning and also prevent future error when `-o nounset` is enabled in the setup hook. For more information, see the discussion at a6bb2ed
FRidh
pushed a commit
to NixOS/nixpkgs
that referenced
this issue
Dec 30, 2019
When `makeWrapperArgs` variable is not set, `declare -p makeWrapperArgs` will return with 1 and print an error message to stderr. I did not handle the non-existence case in b063340 because I thought `mk-python-derivation` will always define `makeWrapperArgs` but `wrapProgram` can be called independently. And even with `mk-python-derivation`, `makeWrappers` will not be set unless explicitly declared in the derivation because of NixOS/nix#1461. I was lead to believe that because the builds were succeeding and I confirmed that the mechanism fails when the variable is not defined and `-o nounset` is enabled. It appears that `wrapPython` setup hook is not running under `-o nounset`, though, invaldating the assumption. Now we are checking that the variable exists before checking its type, which will get rid of the warning and also prevent future error when `-o nounset` is enabled in the setup hook. For more information, see the discussion at a6bb2ed
FRidh
pushed a commit
to NixOS/nixpkgs
that referenced
this issue
Dec 30, 2019
When `makeWrapperArgs` variable is not set, `declare -p makeWrapperArgs` will return with 1 and print an error message to stderr. I did not handle the non-existence case in b063340 because I thought `mk-python-derivation` will always define `makeWrapperArgs` but `wrapProgram` can be called independently. And even with `mk-python-derivation`, `makeWrappers` will not be set unless explicitly declared in the derivation because of NixOS/nix#1461. I was lead to believe that because the builds were succeeding and I confirmed that the mechanism fails when the variable is not defined and `-o nounset` is enabled. It appears that `wrapPython` setup hook is not running under `-o nounset`, though, invaldating the assumption. Now we are checking that the variable exists before checking its type, which will get rid of the warning and also prevent future error when `-o nounset` is enabled in the setup hook. For more information, see the discussion at a6bb2ed
|
I really want this for some patterns... |
|
related discussion: NixOS/rfcs#58 (comment) |
|
In fact, my use case would be something like which seems to me like a verbose way to get a decent pattern of overridable let expressions, which IMHO are sorely missed in the whole overridability story. For something like this, you have no way to override part of the initialCommand, because it disappears from view. { #...
inspect-ast = _lib.makeOverridable (
{ viewer ? lib.viewer {}
, initialCommand ? _lib.makeOverridable (
{ testFile ? lib.qt_aggregated_header
, headers ? [ stdenv.glibc.dev lib.headers lib.llvmPackages.libcxx ]
, args ? [ "-xc++" "-fsyntax-only" "-v" "-fPIC" "-Xclang" "-detailed-preprocessing-record" ]
}:
args ++ (builtins.map (v: " -I " + v) (_lib.makeSearchPath "/include" headers )) ++ [ testFile ] )
, isTruthy ? v: ((v != "") && (v != null) && (v != false) && (v != []))
}:
writeShellScriptBin "ast-viewer" ''
echo ${viewer.passthru.bin} $@ ${ _lib.optionalString (isTruthy initialCommand) ("-- " + (_lib.concatStringsSep " " initialCommand)) }
'');
}{#...
inspect-ast = (lib.inspect-ast {}).override (old: {
initialCommand = old.initialCommand.override (old: old // { inherit headers; });
});
}I think a builtin that returns the attrset lazy in its argument values as usual, but all its arguments available, would be sufficient. Edit: It's been brought to my attention that functors might be a viable alternative to my approach. |
|
I marked this as stale due to inactivity. → More info |
|
People continue to periodically run into this in various public fora including the IRC channels. |
|
I marked this as stale due to inactivity. → More info |
fricklerhandwerk
added
feature
rvem
pushed a commit
to serokell/nixpkgs
that referenced
this issue
Nov 8, 2022
When `makeWrapperArgs` variable is not set, `declare -p makeWrapperArgs` will return with 1 and print an error message to stderr. I did not handle the non-existence case in b063340 because I thought `mk-python-derivation` will always define `makeWrapperArgs` but `wrapProgram` can be called independently. And even with `mk-python-derivation`, `makeWrappers` will not be set unless explicitly declared in the derivation because of NixOS/nix#1461. I was lead to believe that because the builds were succeeding and I confirmed that the mechanism fails when the variable is not defined and `-o nounset` is enabled. It appears that `wrapPython` setup hook is not running under `-o nounset`, though, invaldating the assumption. Now we are checking that the variable exists before checking its type, which will get rid of the warning and also prevent future error when `-o nounset` is enabled in the setup hook. For more information, see the discussion at NixOS@a6bb2ed
|
I just ran into this and was quite confused. |
|
Triaged in the Nix team meeting: Closing, and deferring to RFC 137, which if accepted will allow for controlled breaking changes to the language. Making this a pure addition is likely to be very involved. |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-06-22-nix-team-meeting-minutes-65/29643/1 |
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was somewhat surprised to find that this doesn't work:
(args@{a ? "a"}: ({a}: a) args) {}error: anonymous function at (string):1:19 called without required argument ‘a’, at (string):1:18I had expected that the
@binding would bind the argument set that was actually visible in the body of the function, which would include default values. But it looks like it binds the argument set that was actually passed.Getting the set of all arguments as visible in the function seems pretty useful. There's a particularly obvious use case where you just want to call another function and pass on all of your arguments, which doesn't work currently.
I can see there are probably times when you want the current behaviour, but it would be nice to have a way to get the arguments including default values.
The text was updated successfully, but these errors were encountered: