-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
writeShellApplication: Document and extend arguments #280592
writeShellApplication: Document and extend arguments #280592
Conversation
4a1f0d8
to
3047769
Compare
3047769
to
a231103
Compare
a231103
to
aaf17c8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new tests are awesome, thanks!
I have some comments for the other bits though :)
@@ -152,19 +152,30 @@ rec { | |||
, meta ? { } | |||
, allowSubstitutes ? false | |||
, preferLocalBuild ? true | |||
}: | |||
, ... | |||
}@args: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
runCommandWith
already supports the derivationArgs
attribute with the same purpose (which I also think is cleaner). The same interface can be adopted for writeTextFile
and writeShellApplication
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
writeTextFile
passes all of its arguments to runCommandWith
as derivationArgs
. I don't think this makes sense unless you also support renaming writeTextFile
's checkPhase
argument to derivationArgs.checkPhase
.
In the sense that writeShellApplication
wraps writeTextFile
and writeTextFile
wraps runCommand
, this is just extending the existing behavior to forward arbitrary arguments in addition to the explicitly blessed ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ...
pattern where you pick certain arguments and forward the rest to some mkDerivation
-derivative is just a bit too full of holes imo:
- It makes typos not trigger an error, since
mkDerivation
happily accepts pretty much any value and uses them as environment variables. - It makes it so that you can't use new
mkDerivation
attributes in case they happen to conflict with the picked arguments (what ifmkDerivation
gets adestination
attribute with different semantics?).- And similarly, if somebody passes some derivation attribute, but later that becomes a picked-out function argument, stuff might break.
- It makes the distinction between the stable function interface and internals less clear. In particular setting derivation attributes has the potential to break stuff, whereas the function arguments don't.
- It makes the code less maintainable and harder to understand. Updating function arguments now requires changes in two parts of the code and some thinking. Solutions have been proposed to this, but I think we should just design better interfaces instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I change writeTextFile
's interface as well, to be consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so yeah
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, though I suspect this will cause breakage with callers and confusion around arguments like meta
and checkPhase
which are also stdenv.mkDerivation
arguments.
@@ -367,6 +367,7 @@ rec { | |||
, text | |||
, runtimeShell ? runtimeShell' | |||
, runtimeInputs ? [ ] | |||
, runtimeEnv ? null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reminds me of makeWrapper
, which provides the same functionality via --set <VAR> <VALUE>
. How about we make this function internally use makeWrapper
instead? We can then also use --prefix PATH : ${makeBinPath runtimeInputs}
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makeWrapper
doesn't support setting values to lists or maps. I also think it's nicer to keep the written script contained to one file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, we might want to reconsider this in the future though, especially if the need for more makeWrapper-like features comes up.
/* The name of the script to write. | ||
|
||
Type: String | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately the doc comments here aren't rendered into the manual. Can you follow the style from the very new #277534 instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh they aren't? But we could wire them up, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that could be done with nixdoc
, just like with the lib
docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great improvement, thanks a lot. Finally we can configure the shell!
Note that the checkPhase uses stdenv.shell for the test run of the script, | ||
while the generated shebang uses runtimeShell. If, for whatever reason, | ||
those were to mismatch you might lose fidelity in the default checks. | ||
Similar to `writeShellScriptBin` and `writeScriptBin`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe better:
Similar to `writeShellScriptBin` and `writeScriptBin`. | |
Similar to [](#trivial-builder-writeShellScriptBin) and [](#trivial-builder-writeScriptBin). |
This will render sensibly in HTML now that #277534 is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of directly contradicts what I said in #280592 (comment) 😅
I guess you meant that if this content is moved to trivial-build-helpers.chapter.md
, it would get rendered correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, updated the manual. I'll leave the argument documentation where it is, so it'll get rendered when nixdoc gets wired up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's good to have docs at all, so I don't want to block on this, but really it would be best if the docs were actually visible from the manual instead of people having to look through the source all the time.
Also I want to highlight that @DanielSidhion is recently writing some really nice rendered documentation for function arguments:
### Inputs {#ssec-pkgs-dockerTools-buildImage-inputs} |
Rendered: https://nixos.org/manual/nixpkgs/unstable/#ssec-pkgs-dockerTools-buildImage-inputs
aaf17c8
to
fe2c1bc
Compare
f53b152
to
68d79fa
Compare
Addressed review comments, PTAL. |
68d79fa
to
2e2b0f0
Compare
2188fe9
to
68d79fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops didn't want to force push here yet before I got confirmation first (asked you in PMs), I undid that for now. Mainly I'm suggesting to clean up the Git log, but also to split the bash
stuff into a separate PR, because it's a bit trickier to get right.
I made the changes in this branch, the diff to your current branch is here. Let me know if it sounds good to push like that.
${stdenv.shellDryRun} "$target" | ||
# This is `shellDryRun` but for our particular `bash`. | ||
${bash} -n -O extglob "$target" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stdenv.shell
(or stdenv.shellDryRun
) and pkgs.runtimeShell
are not the same, the former is for the build platform, while the latter is for the host platform. This means that replacing both with the same version breaks cross compilation, and I don't see an obvious way to get around this. That's what I meant with splicing shenanigans being necessary in this comment.
I don't know an obvious way to make this work in a clean way, so I'd say let's have that in a separate PR.
68d79fa
to
41376dd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you pushed my suggested changes, so this definitely looks good to me! Let's merge when CI is greenish and improve anything as necessary going forward.
Description of changes
Documented
pkgs.writeShellApplication
arguments, expanded the test suite, and added several new arguments:The default Bash options can be customized with
bashOptions
.This is useful to e.g. exclude
nounset
if you want to check[[ -n "$myVar" ]]
on a potentially-unset variable, or disablepipefail
to usegrep
in a pipeline. Previously you could doset +o pipefail
, but running that right afterset -o pipefail
always felt clumsy to me.Added a
derivationArgs
argument which is used for extrastdenv.mkDerivation
arguments.This allows customizing
postCheck
and other such parameters.Runtime environment variables can now be set with
runtimeEnv
.I also took care to make sure this doesn't change the hashes of derivations produced with any of the involved functions, so we don't have to worry about excessive rebuilds.
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.