Recipe-level environment variables

[iloveitaly]

Right now, if I want to set an environment variable just for a single recipe, but for all commands executed on that recipe, this is the only way I'm aware of to do this:

test $THE_ENV='hi':
  echo $THE_EN

This works great unless you need to accept additional parameters. Then it breaks.

Here's an example:

test $THE_ENV='hi' *args:
  echo $THE_ENV
  echo {{args}}

And some output:

❯ just test this arg gets assigned
echo $THE_ENV
this
echo arg gets assigned
arg gets assigned

It would be great if it was possible to assign a static recipe-level environment variable.

[chojs23]

Maybe exported parameters with default values alongside variadic parameters, the exported parameter would incorrectly consume command line arguments instead of using its default value.

[chojs23]

This change is a feature, not a bug. Just's parameters are all positional, including exported parameters with default values. #2825 requires a design for per-recipe exports, separate from parameters.

This behaviour is intended so maybe we need new recipe attribute like

[env("VAR1=foo")]
recipeA *args:
  echo $VAR1

[env("VAR1=bar")]
recipe2 *args:
  echo $VAR1

[iloveitaly]

[env("VAR1=bar")]

Something like this seems like a good solution.

[vext01]

You could also add a shebang to make the environment persistent for the duration of the recipe: https://just.systems/man/en/setting-variables-in-a-recipe.html?highlight=shebang#setting-variables-in-a-recipe

[iloveitaly]

@vext01 That is true, although using that approach or the script tag does not provide the robust error detection and echoing of each command, which I generally like.

[vext01]

That's true.

(If your recipe is using a shell shebang, you can append -x (or use set -x) to see lines as they are evaluated, but that won't work for other interpreters)

[neunenak]

This is a feature I've found myself wanting as well, including right this second. I like the idea of implementing this as additional attributes on a recipe. I see that there was this closed PR: https://github.com/casey/just/pull/2844 - I'd like to try to come up with a decent design for what this env attribute might look like and get this or similar code re-opened and merged.

https://github.com/casey/just/pull/2844#issuecomment-3123878342

Syntax for setting recipe-level environmental variables needs to be in the form of expressions which can use values of parameters. Also, parsing as =-separated strings is very inflexible.

I personally like the idea of having an env attribute that takes two arguments, the env var name and then its value. Something like:

[env("NIXPKGS_ALLOW_INSECURE", "1")]
my-nix-command *args:
     nix build .#some-nix-thing {{args}}

I'm not sure how much flexibility we would need/want in making an expression that uses parameter values be in the second argument. @casey do you have any thoughts on what this might look like?

[neunenak]

There's also the issue of the alternate [attribute: "argument"] syntax and how that would play with 2-argument attributes. Maybe something like:

[env: "NIXPKGS_ALLOW_INSECURE", "1"]
my-nix-command *args:
     nix build .#some-nix-thing {{args}}

??

[neunenak]

https://github.com/casey/just/pull/2957 solves my immediate use case.