[Command] env-init command is not possible to override locally

[anjey-aka-pm]

Version of Warden

0.14.3

Operating System and Installation Method

Mac OS 14.3.1 via Brew

Describe the Bug

The default command fallback mechanism allow you to locally override any command for your current environment

if (( "$#" )); then
  ## local project directory if running within one; don't fail if it can't be found
  WARDEN_ENV_PATH="$(locateEnvPath 2>/dev/null)" || true

  if [[ -f "${WARDEN_ENV_PATH}/.warden/commands/${1}.cmd" ]]; then
    WARDEN_CMD_VERB="$1"
    WARDEN_CMD_ANYARGS+=("$1")
    WARDEN_CMD_EXEC="${WARDEN_ENV_PATH}/.warden/commands/${1}.cmd"
    WARDEN_CMD_HELP="${WARDEN_ENV_PATH}/.warden/commands/${1}.help"
    shift
  elif [[ -f "${WARDEN_HOME_DIR}/commands/${1}.cmd" ]]; then
    WARDEN_CMD_VERB="$1"
    WARDEN_CMD_ANYARGS+=("$1")
    WARDEN_CMD_EXEC="${WARDEN_HOME_DIR}/commands/${1}.cmd"
    WARDEN_CMD_HELP="${WARDEN_HOME_DIR}/commands/${1}.help"
    shift
  elif [[ -f "${WARDEN_DIR}/commands/${1}.cmd" ]]; then
    WARDEN_CMD_VERB="$1"
    WARDEN_CMD_EXEC="${WARDEN_DIR}/commands/${1}.cmd"
    WARDEN_CMD_HELP="${WARDEN_DIR}/commands/${1}.help"
    shift
  else
    WARDEN_HELP=1
  fi
else
  WARDEN_HELP=1
fi

This works fine when you have your environment initialized already and .env file is present (as it actively search for .env file inside the locateEnvPath. But if you want to initialize your environment first part of the if condition will actually search for /.warden/commands/${1}.cmd (root folder).
I believe it is reasonable to adjust the check to search in the ./.warden/commands/${1}.cmd current folder instead. This way it will be possible to override env-init command as well

To Reproduce

1. In any empty folder create .warden/commands/env-init.cmd and .warden/commands/env-init.help files
2. While inside that folder run warden env-init --help or warden env-init
3. Actual result: fallback to your home folder or core warden command / help files happens.

Expected Behavior

Expected result: your local newly created files are called

Additional context

No response

[anjey-aka-pm]

Could be something like

  if [[ -f "${WARDEN_ENV_PATH:=$(pwd -P)}/.warden/commands/${1}.cmd" ]]; then

[bap14]

@anjey-aka-pm Maybe I'm misunderstanding your issue, but env-init and env are two separate commands within Warden and call two different files. One is env-init.cmd and the other is env.cmd. The only thing env-init.cmd does is to generate the necessary .env file in the current directory for the specified project type.

The env-init.cmd already specifies that the WARDEN_ENV_PATH is set to the output of pwd -P as you suggest. What you're complaining about is the env.cmd which expects an environment to already be initialized. Once initialized you can define your own custom commands to then run with warden <command>.

The current env-init.cmd only creates the necessary .env file for warden projects, nothing else. What would you need to override the env-init command for?

If you're looking to have custom environment builds (e.g. an environment type we don't have defined) there is a general discussion about rearchitecting the environment initialization to utilize URIs to repositories (possibly with tags) to better support anything you can come up with: https://github.com/orgs/wardenenv/discussions/793

[anjey-aka-pm]

@bap14 first of all thank you for your reply
I'm looking into adding additional variables into .env file itself during the initialization which is performed by env-init command. While overall it is possible for static values thanks to the logic inside fetchEnvInitFile function, which can get the init.env template from the current environment, this is still not possible to do for variables that require some logic.
I.e. it is not possible to prompt for those values and write them inside .env file like it is done inside env-init.cmd here:

cat > "${WARDEN_ENV_PATH}/.env" <<EOF
WARDEN_ENV_NAME=${WARDEN_ENV_NAME}
WARDEN_ENV_TYPE=${WARDEN_ENV_TYPE}
WARDEN_WEB_ROOT=/

TRAEFIK_DOMAIN=${WARDEN_ENV_NAME}.test
TRAEFIK_SUBDOMAIN=app
EOF

And while i'm aware about separate discussion in https://github.com/orgs/wardenenv/discussions/793 i would still insist that the fix i am suggesting is a reasonable quick solution for this. Moreover taking into account that current logic actually scans for the .warden folder in the root directory.

And if we would correctly update WARDEN_ENV_PATH inside warden shell script like i suggested replacing

if [[ -f "${WARDEN_ENV_PATH}/.warden/commands/${1}.cmd" ]]; then

with

  if [[ -f "${WARDEN_ENV_PATH:=$(pwd -P)}/.warden/commands/${1}.cmd" ]]; then

As defined in Shell Parameter Expansion manual

${parameter:=word}
If parameter is unset or null, the expansion of word is assigned to parameter, and the result of the expansion is the final value of parameter. Positional parameters and special parameters may not be assigned in this way.

This one-line fix will both resolve issue of scanning root folder for warden files as well as will allow us to override env-init.cmd

[navarr]

I think I understand your request and fix, and what you're saying makes sense.

The only thing I can't figure out is why? I suppose it's not that important, but curiosity is killing me here. Why would you want to override env-init on a project level?

[anjey-aka-pm]

Hi @navarr

I have complex structure for magento2 project which have multiple composer.json/lock files inside (let's call them environments). They all using single local composer repository for custom modules, just different modules combination on different environment. It spins up the additional php-fpm/debug + nginx containers for every project, doing some black magic with subpath docker volumes and traefik configuration to make it work nice and smooth and having single warden environment handle them all.
They all benefit from single db (that was the main reason for it), redis, etc. containers and this actually highly reduces the resource usage for docker while we run automated tests.

Same environment setup is used during development, but different developers are responsible for different set of environments and they only need some of those up in their installation. For that one i have additional variable inside of .env file which allow to limit the environments i want to spin up. Also the variables which control default shell / debug container (current environment).

I have extended every related command like shell.cmd, debug.cmd, etc to make it work (they still rely on the base warden commands just do some per-initialization before calling the fallback command.

Now i want an interactive prompt during env-init for the developer / qa to be able to select which environments is needed, for that one i need a possibility to have project-specific env-init.cmd (as i do read list of existing environments and do validate the input). Currently in order to spin it up they do warden env-init (which loads custom init.env file) + additional command i.e. warden env set-environment-list (yes i also added some custom sub-commands).
I want it to be able to do it only via warden env-init

[navarr]

Fair enough, @anjey-aka-pm, thank you for sharing!

I can add this to the list. Please be warned though that time on this project is limited so I cannot guarantee speed of it.

[anjey-aka-pm]

@navarr would you like me to prepare a PR for it ?

[navarr]

@navarr would you like me to prepare a PR for it ?

That would increase its odds of actually getting done ^^;