I am having an issue after upgrading to 1.0.1. I edited one of my environments and when it activates again I get this message:
/Users/etorreborre/.cache/flox/run/etorreborre/ockam.9c6cb2142223c368f7ae284619de6e8b0bc0a8dcbf47ddf7949aa687ee698051/activate/zsh:13: setopt: command not found
/Users/etorreborre/.cache/flox/run/etorreborre/ockam.9c6cb2142223c368f7ae284619de6e8b0bc0a8dcbf47ddf7949aa687ee698051/activate/zsh:14: setopt: command not found
we’ll look at it right away. we implemented setopt to handle a situation where newly installed packages weren’t getting into environments and this seems to be an unintended side effect. track this for updates, will try to follow-up here if we get a resolution and timing! activation does not work when setopts is not available · Issue #1174 · flox/flox · GitHub
In the past command path hashing has prevented users from seeing newly installed software within their Flox environment (i.e. the shell had a system python command path cached and did not pick up a floc installed version).
setopt is used to prevent zsh from hashing commands for the duration of a Flox environment apparently it’s the zsh alternative to set +h in bash.
Since setopt is a builtin in zsh, we wouldn’t expect this to ever be a concern unless the scripts are executed in the wrong shell (i.e. bash) for some reason.
Could you post your value of $SHELL and (presuming that you use zsh, zsh --version)?
Do you have $FLOX_VERSION set to anything?
Previous versions would export FLOX_VERSION to activated shells, if you were to activate an environment within one activated by an older flox version you might still have a conflicting version set.
Is there a chance that the activation with setopt: command not found was ran in a bash subshell?
For some background I only get to reproduce this when running SHELL=zsh bash -c 'eval "$(flox activate)"' because flox respects currently expects $SHELL to be the same as the executing shell (our plan is to improve that, but it would be good to confirm that your issue is indeed related to that).
ah, I’'d need to check but i think direnv executes .envrc in bash always, thus the iscrepancy between SHELL and parent shell.
Thanks that is helpful.
For a workaround you can edit your .envrc to