Skip to content
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

Unexport environment variables per recipe using attribute #2409

Closed
W1M0R opened this issue Oct 3, 2024 · 2 comments
Closed

Unexport environment variables per recipe using attribute #2409

W1M0R opened this issue Oct 3, 2024 · 2 comments

Comments

@W1M0R
Copy link

W1M0R commented Oct 3, 2024

Currently, environment variables can be unexported at the justfile level, using unexport. This will unexport the environment variable for all recipes:

unexport GIT_EXTERNAL_DIFF
unexport GIT_PAGER

# only this recipe should not have GIT_EXTERNAL_DIFF and GIT_PAGER exported
diff-delta:
  git diff | delta --line-numbers

# and this recipe should respect the parent shell's GIT_EXTERNAL_DIFF and GIT_PAGER, but won't due to the unexport statements
diff-default:
  git diff

In some cases it is helpful to unexport (in a cross-platform way) an environment variable (or a list of environment variables) for only a specific recipe. One workaround is to use submodules, e.g. justfile-git-defaults.just and justfile-git-overrides.just, but this feels cumbersome.

Ideally, it would be nice to be able to unexport using an attribute:

[unexport("GIT_EXTERNAL_DIFF", "GIT_PAGER")]
diff-delta:
  git diff | delta --line-numbers

diff-default:
  git diff

Related:

  1. Setting environment variables on a per-recipe basis without $-parameters #2408
@neunenak
Copy link
Contributor

neunenak commented Oct 4, 2024

Seems to me that this issue should be combined with #2408 - the actual desired feature is a way to scope anything one can currently do with just variables to a single recipe (or maybe a group of recipes?), whether that's exporting, unexporting, etc.

@casey
Copy link
Owner

casey commented Oct 5, 2024

Yah, closing in favor of #2408, since whatever solution we come up with should handle both cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants