Regression with flox 1.0.5

Bug Reports
1

Hi, there seems to be a regression with flox 1.0.5.

I am now seeing this message again:

/Users/etorreborre/.cache/flox/run/etorreborre/default.d62f59a1/activate/bash:13: command not found: shopt
/nix/store/0bscac2mkvbgr21nvj63r0hgwqfwmy17-set-prompt.bash.sh:16: command not found: shopt

This is when I enter a directory with direnv and my configuration is

eval "$(flox activate -d $FLOX/my_env)"

Then I get a direnv message:

direnv: ([/Users/etorreborre/.cache/flox/run/etorreborre/default.d62f59a1/bin/direnv export zsh]) is taking a while to execute. Use CTRL-C to give up.
2

We’re looking into it! we made a number of activate changes in this release. will get back to you shortly

3

With 1.05 we changed the order of hook.on-activate and profile scripts such that the hooks are always run first now (and always in Bash). This allows you to eval in your hook and it should just work in most cases.

Could you share your manifest so I could take a look and do some debugging?

4

Thanks for helping. I sent the result of flox -vv activate and my manifest file to Michael via the Slack workspace.

1 Like
5

Thanks again Eric for sending those traces offline. We’ll get back to you ASAP with a workaround. :+1:

6

Thanks again Eric for your patience. As a workaround, please try:

eval "$(FLOX_SHELL=bash flox activate -d $FLOX/my_env)"

The reason for the problem is because direnv always parses the contents of .envrc in a (non-interactive) bash sub-shell, irrespective of the shell that you are using. (This is similar to the way that the flox on-activate hook is always processed using bash, for much the same reasons.) The FLOX_SHELL environment variable provides a way to override the flox shell detection logic in the meantime, but I’ll also update the code to always switch into bash mode when we detect direnv as the parent process of the flox invocation.

Thanks again for the bug report!

7

Hi Eric, I think I know what’s going on.

Your use of direnv is taking place within an existing flox activation, and it is that outermost flox activate invocation that is a) correctly detecting your shell as /bin/zsh and b) leaking the FLOX_SHELL=/bin/zsh environment variable into your subsequent environment. As a result, when you use direnv it invokes flox with FLOX_SHELL defined and pointing to zsh, which then causes flox to emit zsh syntax when direnv invokes flox from the .envrc (using bash).

The fix for this should be to stop leaking FLOX_SHELL into the environment - I’ll draw up a PR for that ASAP.

Here’s a reproducer that illustrates the behavior:

flox [limeytexan/default (remote)] brantley@Michaels-MacBook-Pro ~ % echo $FLOX_SHELL

flox [limeytexan/default (remote)] brantley@Michaels-MacBook-Pro ~ % cd direnvtest
direnv: loading ~/direnvtest/.envrc
direnv: export +DYLD_FALLBACK_LIBRARY_PATH ~ACLOCAL_PATH ~CPATH ~FLOX_ENV ~FLOX_ENV_CACHE ~FLOX_ENV_DESCRIPTION ~FLOX_ENV_DIRS ~FLOX_ENV_DIRS_activate ~FLOX_ENV_LIB_DIRS ~FLOX_ENV_LIB_DIRS_activate ~FLOX_ENV_PROJECT ~FLOX_PROMPT_ENVIRONMENTS ~FLOX_PROMPT_ENVIRONMENTS_activate ~INFOPATH ~LIBRARY_PATH ~MANPATH ~PATH ~PKG_CONFIG_PATH ~XDG_DATA_DIRS ~_FLOX_ACTIVE_ENVIRONMENTS ~_add_env ~_del_env
flox [limeytexan/default (remote)] brantley@Michaels-MacBook-Pro direnvtest % cd ..
direnv: unloading
flox [limeytexan/default (remote)] brantley@Michaels-MacBook-Pro ~ % export FLOX_SHELL=$SHELL
flox [limeytexan/default (remote)] brantley@Michaels-MacBook-Pro ~ % echo $FLOX_SHELL        
/bin/zsh
flox [limeytexan/default (remote)] brantley@Michaels-MacBook-Pro ~ % cd direnvtest
direnv: loading ~/direnvtest/.envrc
/private/tmp/direnvtest/.flox/run/aarch64-darwin.direnvtest/activate.d/zsh:36: unexpected token `(', conditional binary operator expected
direnv: export +_flox_activate_tracelevel -FLOX_ORIG_ZDOTDIR ~FLOX_ENV ~FLOX_ENV_CACHE ~FLOX_ENV_DESCRIPTION ~FLOX_ENV_DIRS ~FLOX_ENV_LIB_DIRS ~FLOX_ENV_PROJECT ~FLOX_PROMPT_ENVIRONMENTS ~FLOX_ZSH_INIT_SCRIPT ~_FLOX_ACTIVE_ENVIRONMENTS ~_add_env ~_del_env
flox [limeytexan/default (remote)] brantley@Michaels-MacBook-Pro direnvtest %

Will let you know once we release a patch for this.

1 Like
8

Great investigation, thanks Michael.

9

And … the fix for this was merged with fix: do not leak FLOX_SHELL into subsequent activations by limeytexan · Pull Request #1493 · flox/flox · GitHub which should be included with v1.0.6. So if you can just unset FLOX_SHELL when you see this bug in the span between now and then then you shouldn’t ever have to think about it again! :slight_smile:

Thanks again for all the great feedback!

1 Like