feat(entrypoint): fixes/improvements to support nix run (devshell-as-flake-app)
#243
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
rather than the source/raw entrypoint that contains `@DEVSHELL_DIR@` instead of the substituted output path.
which was, previously, the raw/source `entrypoint` (prior to substitution of `@DEVSHELL_DIR@`), and is now the `env.bash` file from the final `devshell_dir`.
even when it is already set when sourcing env.bash.
via doing `return 0` in a subshell instead of testing whether `$0` and
`${BASH_SOURCE[0]}` are identical (the latter method is subject to
false negatives).
to avoid tripping `set -u`
by dynamically setting "$@" on the basis of, e.g., whether or not we saw the `--pure` option.
that supports options in parameters other than "$1" and lays the groundwork for introducing additional options.
for specifying "$PRJ_ROOT" prior to sourcing "env.bash" (which will bail out if "$PRJ_ROOT" is unset or empty). Using "--prj-root" may be more convenient than setting an environment variable when, e.g., using the entrypoint as a Nix flake app.
for specifying the "env" executable. This is mostly for the automated test suite, as "/usr/bin/env" is not available within the test script environment.
thus demonstrating support for `nix run`.
|
I've just pushed some updates:
Edit: I also broke some stuff, but it's fixed now :) |
via the new option "devshell.prj_root_fallback". This option, if set to a non-null value, is used to set the value of "$PRJ_ROOT" in case it is not set in the controlling environment, the entrypoint script did not get a `--prj-root` option, "$IN_NIX_SHELL" is empty or unset, and "$DIRENV_IN_ENVRC" is unset or any value other than "1". The default option definition sets "$PRJ_ROOT" to the value of "$PWD".
|
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was poking at a
devshellderivation innix replrecently when I noticed itsflakeAppattribute. This is a cool feature! I would love to be able tonix run '.#my-devshell' -- <command>and access commands from my devshell without having to first enter anix developsesson. It looks like theflakeAppdefinition needs some updates to account fordevshell.nixrefactors; this PR is my attempt to apply those updates. It also adds some convenience features, like a CLI option for specifying the project root path.Have a few questions I'd like to resolve before removing "Draft" status from this PR:
flakeApp/nix run, where would you like me to document it? I took a look at the files in./docsand nothing jumped out as an appropriate spot.PRJ_ROOTwhen running the devshell entrypoint as a flake app? Seems likePRJ_ROOTshould refer to the flake's root directory? For instance, maybe a devshell command references files in the flake by expanding them relative toPRJ_ROOT. UsingPWDasPRJ_ROOTin this circumstance might work, as long asPWDis the working tree toplevel of the git repository for the flake providing the devshell. But it almost certainly wouldn't work if trying tonix run 'some-other-flake#devshell-flake-app'. On the hand, maybe there are also cases wherePRJ_ROOTshould refer to (say) the current working directory -- for instance, maybe I want to run a linting command provided by a "foreign" flake, and that command searches for files that live underPRJ_ROOT.apps.<system>.devshell, as a kind of demo of theflakeAppfeature. Is this worthwhile? If so, should it be advertised somehow (in the README, or elsewhere)?Thanks!