Add lazy variable evaluation with `lazy` keyword

[MasterNayru]

I have been checking #953 for many years now waiting for this feature to land and getting all frustrated and bent out of shape, and after having to write another Makefile, I have started hate writing Rust to put some simple implementation forward rather than suffer in silence.

This PR implements lazy evaluation for variable assignments using a new lazy keyword. This is something that had been discussed as a potential way forward by someone, and as we all know if two people on GitHub give it a tick that is all the green lights we need.

The main motivation for this is that over the years I have been unable to really suggest just as an alternative because I often need to get things like credentials to log into AWS services or some such, and having them execute on every invocation just gets way too expensive.

I am not sure what I need to update in terms of the documentation, grammar, etc. but I thought I would at least put this forward and let everyone throw tomatoes at it so at least I gave addressing the issue a try.

I have tried to write tests for this that, hopefully, cover all of the bases and edge cases, but my experience with the more exotic features of just is somewhere between zero and very limited.

Usage:
  lazy credentials := `aws sts get-session-token`

  # credentials are only evaluated if this recipe runs
  deploy:
    ./deploy.sh {{credentials}}

Fixes #953

[BoolPurist]

Cool feature. Looking at your tests though. I do not find any asserting if a variable assignment is only done once.

Maybe a test case where you produce a random number and see whether printing the variable remains the same ?

[MasterNayru]

@BoolPurist That's an excellent idea, I hadn't considered that. I have added a test that generates a timestamp and ensures that it is the same value when referenced more than once. It does only evaluate the value once.

[BoolPurist]

@MasterNayru Nice, your approach of the timestamp for testing if evaluated only once is even better/simpler compared to generating a random number.

[BoolPurist]

I am not sure what I need to update in terms of the documentation, grammar

In my opinion the usage of this feature might be best put in its own chapter aka under its own MD heading within the README. Maybe after the section with MD Heading called "Expressions and Substitutions".

There is also a grammar file where this new keyword lazy should be inserted. My guess would be that it belongs into grammar rule assignment under MD Heading grammar,

Maybe replace

assignment    : NAME ':=' expression eol

with this

assignment    : 'lazy'? NAME ':=' expression eol

[MasterNayru]

I can certainly push a change up that does a best-guess at this. I was just reluctant to push a bunch of stuff that was wrong that some poor maintainer then needs to correct. This is my first contribution to a project of this size, and I don't have much experience in Rust as I learnt just enough to write this change. I was hoping that the change would be small enough that getting this over the line wouldn't involve me playing guessing games as to what should go where.

If I see someone munge another Makefile of mine with macros and function calls, my eyeballs will roll out of my head and run away, so I just want to do whatever it takes to get the feature in as this feature not being there has meant that I couldn't introduce it at the last 3 companies that I've worked at.

[BoolPurist]

I can certainly push a change up that does a best-guess at this. I was just reluctant to push a bunch of stuff that was wrong that some poor maintainer then needs to correct.

Fair enough. To me, you did good work so far. I appreciate that you followed my suggestion.

About my suggestion for adding the documentation. It is my belief that your implementation of this suggestion of adding this documentation at these places is helpful for the maintainer even if the maintainer needs to correct things. If these changes now cause more trouble than It is worth then I am in the wrong, sorry about that and need to rethink what is useful for the maintainer in the future.

I hope this feature will be merged. Here is my informal approval of this PR.