Feature: `required_version` setting to improve error reporting

[zekefast]

Problem

I support fairly large just code base as for build script and eagerly looking into CHANGELOG.md with each release for new features, attributes, functions, etc. with each new version of just. Then I usually see opportunity to improve our scripts and integrate these new features into our code base, using fresh version of just.

I push my changes, but when they arrived to machines of other engineers it is usually a case that they have older version of just and haven't updated it for awhile. That lead to situations where just code base brakes and it is not very clear immediately why. Was it bug in scripts which does not account for the differences in developers' machine or just older version of just. And error message usually isn't clear for people who has very little experience with just or focusing daily on other dev tasks and not writing justfile's regularly.

Though I don't have exact error message and attribution to particular feature right now at hands. But situation keep occurring again and again. And learn to ask the first question whether people have up to date version installed.

Proposal

Introducing ability to specify version requirements in justfile as a setting would allow to generate meaningful error message about just version contradiction instead of having message about unknown attribute, function or other thing.

Most appealing to me is to have required_version setting similar it was done for terraform.

So, in justfile it would look something like:

set required_version = ">= 1.43.1"

just before generating any error messages would check version requirements and output message about outdated just version installed on users machine and need to update it before keep using specific justfile.

I think it would be simpler to having this as a global setting affecting all loaded justfiles, though it at edge case it may have a sense to load it per justfile. But in case of having it as justfile specific setting I see a compilations in explaining that feature to users and implementation probably would be more complex. So, global settings seems as a good start.

Possible implementation issues

The setting probably won't cover all the possible changes, i.g. like new operators or new syntax constructs of just language as it would be, probably, problematic to parse justfile partially and retrieve only required_version setting and ignore parsing errors for not supported new syntax.

To support this scenario I may assuming we need to filter the settings from justfile and try to load them separately or using different kind of parsing technics (i.e. not a recursive descent parser). But I would like to hear more views about this issue from authors and maintainers of just.

Implementation Plan

I took a look into just code base and the change probably would fairly small.

• Extend Setting enum with new variant
• Add support for parsing new setting in Settings::from_table() function
• Add version comparison and checks somewhere in Analyzer::justfile()
• Add tests
• Add description of new setting to the book

Workaround

In some repositories I have both just and mise. So, I install just using mise and do version control in mise.toml file. That works quite good, but not always possible. So, I would prefer to have something in just to check version as well.

[laniakea64]

https://github.com/casey/just/issues/2290

[zekefast]

@casey What do you think about having required_version attribute and implementation plan? I can prepare PR if it sounds as a useful feature to you and other maintainers

[zekefast]

@laniakea64 Or nice! I haven't found that somehow! Though I search by required only.

[zekefast]

I just thought and I thing we can do tow pass parsing, i.e. first pass normal parsing and second in case of errors tries to parse only settings (e.g. string starting with new line and then set). Then we should be able to report version errors.

WDYT?