Add env attribute to set environment variables for recipes

[neunenak]

The env attribute accepts two arguments (env_var, value) and can be used multiple times per recipe to set environment variables without using the existing $parameter syntax:

[env('API_KEY', 'secret')]
[env('LOG_LEVEL', 'debug')]
deploy:
    ./deploy.sh

Addresses #2825

[neunenak]

Also as a general note, I initially generated this PR with LLM coding tools and then manually audited+tweaked some things. I dunno if just as a project does or should have some kind of stated policy on that, but I wanted to mention that for the sake of transparency.

I'm personally pretty bullish on AI-assisted coding, I do it all the time myself, and I take the position that in general a human developer is responsible for the code they submit to a project, but the project shouldn't care exactly how they generated that code.

[neunenak]

@casey it'd be great if you could take a look at this, I think this is a pretty simple change that yields a pretty useful feature

[casey]

This looks good. Some minor tweaks.

A couple bigger questions:

Should exported environment variables should be available to recipe parameters?

[env("foo", "bar")]
baz x=`echo ${foo}.txt`:

Also, should they be available to env functions?

[env("foo", "bar")]
baz:
  echo {{ env("foo") }}.txt

I think the answer to both is probably yes.

As far as AI goes, I have no problem at all with LLM and AI generated code, as long as you the human coder "vouches" for the code to the same degree as code you wrote yourself, which requires reviewing the whole thing in depth before submitting it.

[casey]

Actually, maybe they shouldn't be available to env functions. The env functions don't see exported top-level assignments or parameters, so the env attribute shouldn't be an exception. The question about parameters remains.

[neunenak]

Actually, maybe they shouldn't be available to env functions. The env functions don't see exported top-level assignments or parameters, so the env attribute shouldn't be an exception. The question about parameters remains.

This is actually potentially confusing behavior with env(), although altering this would be a breaking change. In any case, I implemented making environment variables set via env accessible in parameters but not via env(). I think it's fine to deter thinking about what the right way for env() to behave is to another issue.

[neunenak]

@casey could you take a look at this?

[casey]

Looks good! Sorry for not thinking of this earlier, but I think that a duplicate variable name in an [env] attribute should be an error, since it's almost certainly a mistake.

[casey]

Nice, merged!