During snap install, we commonly need to configure a generic config file that has invalid or dummy values built into the snap with runtime files and sometimes we need to use tools available in the core snap (i.e. sed, grep, awk) to do this such as jq, so we stage those tools into the snap.
In normal snapcraft.yaml defined apps, the environment variables get setup such that we can just use "jq" in a shell script and it is on the $PATH with $LD_LIBRARY_PATH set appropriately, but we need to use jq from a hook and the environment variables aren't setup at all for hooks. This may be by design but is unfortunate as now we have code like this:
```
# add things from the snap's $PATH to here
export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH"
# setup LD_LIBRARY_PATH, we need to handle the different architecture paths -
# this snippet is copied out of one of the generated snapcraft wrappers
case $(arch) in
x86_64)
MULTI_ARCH_PATH="x86_64-linux-gnu";;
arm*)
MULTI_ARCH_PATH="arm-linux-gnueabihf";;
aarch64)
MULTI_ARCH_PATH="aarch64-linux-gnu";;
*)
echo "architecture $ARCH not supported"
exit 1
;;
esac
# Note - the env var SNAP_LIBRARY_PATH is set by snapd for hooks, so it can be referenced here
export LD_LIBRARY_PATH="$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/$MULTI_ARCH_PATH:$SNAP/usr/lib/$MULTI_ARCH_PATH"
```
It would be great if snapcraft or snapd could somehow facilitate adding generic boilerplate code like this for hooks. One easy way I think would be to have snapd gain support for command-chain for hooks like it does for apps today and then in the snap.yaml it would have a snapcraft generated hook that runs before the actual hook in the snap.
In snapcraft, if you create the hook through a part, command-chain will be properly setup with the right environment, the hooks need logic to install to $SNAPCRAFT_
The case you are presenting is probably the case where you just add hooks to <project_
The fact that the environment keyword at the root of a project is not respected was a snapd issue that has since been solved https:/
I am marking the snapcraft issue as Invalid for such reason, and will let the snapd team attest to what I wrote and triage appropriately.