A weird python install

Hi, I tried to install python3 and got the following

~/projects/rust/ockam on develop
± flox install -e ockam python3                                                                                                                                                                                                                                                                                                                                       ockam

~/projects/rust/ockam on develop
± flox list -e ockam                                                                                                                                                                                                                                                                                                                                                  ockam
    Alias     ockam
    System    x86_64-darwin
    Path      /Users/etorreborre/.local/share/flox/environments/etorreborre/ockam
    Curr Gen  2

    0 stable.etorreborre.ockam.0_77_0
    1 stable.nixpkgs-flox.python3

~/projects/rust/ockam on develop
± which python                                                                                                                                                                                                                                                                                                                                                        ockam

~/projects/rust/ockam on develop
± python --version                                                                                                                                                                                                                                                                                                                                                    ockam
Python 2.7.16

Python being listed as stable.nixpkgs-flox.python3 then returning 2.7.16 is really weird. But, not being a python developer, I might be missing a subtlety.

Could I be again a victim of not running hash -r? If so it would be great to add it to the flox install command.

Hi Eric!

This is indeed, strange. I can’t replicate this on my local (Ubuntu) install. Our Python3 builds seem to be building fine for 86_64-darwin.

What version of flox are you running?
Can you check whether you have several environments active?

I’m looking into this further. Thanks!

Are you using zsh? Because it’s fairly possible that you can only reproduce this if you encounter this issue: linux - zsh running a comand but not from the path - Super User

I am not using zsh. We did ship some updates which handle zsh better with the latest flox version. I would recommend upgrading if you haven’t yet.

I’m on 0.0.6-r58. I’ve been recently upgrading with flox upgrade flox.flox-prerelease and with this it seems that I’m on the latest version.

Yeah seems like it’s likely hashing related. On macOS with zsh:

~  > flox list -e py3
    Alias     mkenigs/py3
    System    aarch64-darwin
    Path      /Users/matthew/.local/share/flox/environments/mkenigs/py3
    Curr Gen  

~  > flox install -e py2 python2
~  > flox activate -e py2
Agent pid 97868
Identity added: /Users/matthew/.ssh/id_ed25519_yubikey (matthew@floxdev.com)
flox [py2 default] ~  > flox activate -e py3
INFO environment not found: /Users/matthew/.local/share/flox/environments/mkenigs/py3
Agent pid 98097
Identity added: /Users/matthew/.ssh/id_ed25519_yubikey (matthew@floxdev.com)
flox [py3 py2 default] ~  > set -h
flox [py3 py2 default] ~  > python --version
Python 2.7.18
flox [py3 py2 default] ~  > flox install -e py3 python3
flox [py3 py2 default] ~  > python --version
Python 2.7.18
flox [py3 py2 default] ~  > hash -r
flox [py3 py2 default] ~  > python --version
Python 3.10.7

Hi @etorreborre - if I’m not mistaken, @mkenigs append confirms you need to use hash -r with zsh. I’m unclear if we can add it to the flox install command if it only happens with zsh, but I’ll put it on the list to have a look. :slight_smile: In the meantime though I believe you have this workaround; if this is not the case, please do let me know.

1 Like

Hi Robin, yes the workaround works for now. I think it could really make sense to integrate it to any activation:

  • because when you don’t know about it, it is really not obvious that hash -r could be the solution (I didn’t know that zsh behaved this way)

  • even if you know it, you might forget to do it and be puzzled until you remember

  • even if you know it and remember about it, this is one more step that you have to manually do, “just in case”, instead of just activating an environment and forgetting about this issue

  • it seems that bash is also prone to a similar issue

No worries, we have a ticket internally and they are looking to get it sorted, I just can’t say the timeframe but hopefully not too long. :slight_smile:

1 Like

The problem is hash -r is a shell builtin, so if we run it in flox, it won’t affect the calling shell. So I think the best thing we could do is document hash -r or try to detect when running it is necessary and print please run "hash -r"

Maybe we can recommend add this to the shell configuration:

. <(flox activate)

This will always clear the cache from previous invocations.

Yeah or alternatively set +o hashall. We could also add that into the script that flox activate prints (since that’s getting sourced), but that feels a bit invasive to me

virtualenv dealing with the same issue: venv: Suppress warning message when bash hashing is disabled. by d-goldin · Pull Request #17966 · python/cpython · GitHub


Hey we think this issue may have been resolved.
Please let us know if it persists.

Thanks for the report!

1 Like

Will do, thanks Alex!