Consider adding set unstable setting

[FelixZY]

It seems just does not recognize JUST_UNSTABLE if it is set using a .env file.

[casey]

I don't think this can be easily supported. .env files are loaded after compiling the justfile, and JUST_UNSTABLE is used during compilation, to turn on unstable features.

I'm wondering why we don't have a setting, set unstable, which allows unstable features. We would have to defer warnings about unstable features until after compilation, since that is when we would have access to the setting, but otherwise it shouldn't be too tricky.

[casey]

I haven't thought too hard about set unstable, and whether or not it's a good idea, so feedback welcome, pro and con.

[FelixZY]

I just started using just yesterday so I'm still a bit new to how it works. However, the most clear pro and con I can see is that:

• Pro: unstable features can be enabled on a per-project basis
• Con: users are automatically opted-in to unstable functionality. Depending on why the functionality is deemed unstable this may or may not be a problem. (Personally I think the pro outweighs this concern)
• Something to think about: how would this interact with modules? Will the setting be required only in the root file, relevant files (yay for this!) or all files?

Given my original request, I'm guessing I could do something like this if I still wanted to use env vars with set unstable?

set unstable := env_var_or_default('ENABLE_UNSTABLE_FEATURES', 'false');

[laniakea64]

Con: users are automatically opted-in to unstable functionality.

Huh? 😕 The "users" in this case are justfile authors. Only users who specifically want "unstable" (which IIUC in this context only means "maybe subject to backwards-incompatible breaking changes") functionality would enable the setting. The only thing "automatic" about it is that using this particular justfile wouldn't require passing --unstable or exporting JUST_UNSTABLE=1, or am I missing something?

Given my original request, I'm guessing I could do something like this if I still wanted to use env vars with set unstable?

set unstable := env_var_or_default('ENABLE_UNSTABLE_FEATURES', 'false');

Setting values can't be expressions.

[FelixZY]

Huh? 😕 The "users" in this case are justfile authors.

I was thinking of project collaborators who would get this flag enabled after the justfile is shared in git. But again, it probably isn't an issue.

[gl-yziquel]

@FelixZY As a "quick" fix, I suggest using direnv.

Works like a charm on my box, though it's kind of global and not local.

While I believe the set unstable would be a good idea, long term, if most use cases can be achieved with direnv, then I'd advise against making too early such a development decision before use cases are ironed out.

Sure, it's a bother to provide a CLI tool written in just and say "hey ! you need to enable JUST_UNSTABLE in your environment". But you can always use a shebang to make your justfile executable: I use #!/usr/bin/env -S just --justfile for the executable justfile shebang. Adding an --unstableflag should do the trick.

The use case that bothers me is that I like to dump Justfiles in my git repos and just run just to get my stuff to just work. Doing just --unstable build is ugly. I want just build. So I need export JUST_UNSTABLE=true in my direnv .envrc. As I also use .envrc for other stuff, I just can't commit it, and I don't think one should, in the abstract. So I have to instruct the person who checks out the repo to enable it manually. Which is not good.

This is the only use case I can think of where direnv and shebangs do not cut it.

You can always make the root Justfile of the repo executable with an unstable shebang, and run ./just build instead of just build, but, well... ugly.

But I may need to use ./just anyway instead of just if I need a pre-processing stage to generate dynamically and not statically some just repices in a just module. So I'm still split on the opportunity of using set unstable in a Justfile.

However, I do not really see the value of the unstable behaviour being local and not global.

Weirdly enough, I think the following ugly solution is less ugly than it seems: Use an unstable suffix to the Justfile. If you run just in a folder with Justfile, it's stable. With Justfile.unstable, it's unstable. This way, the compile time logic of how you use mod and import is kept separate from the OS-level / shell-level of the just invocation. The unstable behaviour is (Justfile + mod + import)-wide, whereas just something invoked in recipes get promoted to unstable behaviour if the file path has the unstable suffix.

[laniakea64]

Done in #2237 ?

[casey]

Yup! Thanks for reminding me.