Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
v1.3.0
Released 2023-02-19
Features:
garden eval and garden expressions in general will now resolve variables defined
within environment blocks. Environment blocks were previously not considered when
resolving variables. Environment blocks are now resolved and checked for variables
when ${variable} expressions do not find the variable in scopes with higher
precedence. The precedence order, from strongest to weakest, is the variables
block in a garden's scope, the variables block in a tree's scope, the
variables block in global configuration scope, the environments block in
a garden's scope, the environments block in a tree's scope, the
environments block in global configuration scope and, lastly, OS environment
variables. The first entry found is used when expanding variable expressions.
(#23)
Evaluation cycles (i.e. circular variable dependencies) are now prevented when
evaluating garden variables. The evaluation engine will now return empty strings
when a variable with a cyclical expression is evaluated.
(#24)
When zsh is used as the garden.shell, which happens automatically when zsh
is installed, garden will now use zsh -o shwordsplit in order to enable
word-splitting of $variable expressions by default. This makes zsh behave
just like other shells by default, which improves the portability of commands.
Configure garden.shell-wordsplit to false or use the
garden <cmd> -z | --no-wordsplit option to opt-out of this behavior.
(#25)
garden.shell can now be configured to use arbitrary commands for executing
command strings. Garden uses the configured garden.shell as-is and does
not augment its options (e.g. -e or -o shwordsplit) when a custom command
is used. Custom commands are identified as commands that expand to 2 or more
command-line arguments. Thus, python3 is not considered a custom command
and garden will run python3 -c <string> to run commands. On the other
hand, specifying ruby -e is considered a custom command because it
expands to ["ruby", "-e"] under the hood. If you need to use a custom
command that takes no additional command-line arguments then you can
use env as an extra argument to have it be considered as a custom shell.
For example, env custom-shell will cause garden to run
env custom-shell <string>, which is equivalent to custom-shell <string>.
Using just custom-shell would have resulted in garden running
custom-shell -c <string> instead, which may not be desired.
(#26)
The garden shell command can now be configured to use an interactive command shell
that is distinct from the command specified in the garden.shell configuration by
configuring the garden.interactive-shell value.
(#26)
garden shell can now be run without any arguments. The tree query now defaults to
. so that the tree in the current directory is used when nothing is specified.
(#26)
Custom commands now have access to a ${GARDEN_CMD_VERBOSE} and ${GARDEN_CMD_QUIET}
variables which can be used to forward the --verbose and --quiet arguments
down into child garden invocations. ${GARDEN_CMD_VERBOSE} uses the short -v
flag in the value to support the case where the verbose option is specified
multiples times to increase the verbosity level (e.g. -vv).
(#27)- Loading branch information
