Fix first experiment run docs

[d-led]

Problem 1

trying to activate the (mini)conda environment fails with the commands described in the environment_arm64.yml:

% conda init
no change     /opt/homebrew/Caskroom/miniconda/base/condabin/conda
...
No action taken.

% conda activate tbp.monty
CondaError: Run 'conda init' before 'conda activate'

the internet suggests a quick-fix, commented in the proposed change

Problem 2

Downloading the habitat as described in the readme fails due to a wrong python module:

% python -m habitat_sim.utils.environments_download --uids ycb --data-path ~/tbp/data/habitat
/opt/homebrew/Caskroom/miniconda/base/envs/tbp.monty/bin/python: No module named habitat_sim.utils.environments_download

The download works when switching to the datasets_download module

CLA

CLA should have been signed successully

[tristanls]

Thank you @d-led.

Regarding Problem 1, I'm trying to figure out what commands you executed. I see you ran conda init. Is this the command sequence you ran?

conda env create --file environment_arm64.yml --subdir=osx-64
conda activate tbp.monty
# is this where you got the error?: CondaError: Run 'conda init' before 'conda activate'
conda init
source ${miniconda_dir}/base/bin/activate base
conda activate tbp.monty
# success?

Regarding Problem 2, thank you for catching that.

Regarding CLA, if you already signed the CLA here, it may take some time before your signature is processed. We will make improvements to this in the near future.

[d-led]

Thank you @d-led.

Regarding Problem 1, I'm trying to figure out what commands you executed. I see you ran conda init. Is this the command sequence you ran?

conda env create --file environment_arm64.yml --subdir=osx-64
conda activate tbp.monty
# is this where you got the error?: CondaError: Run 'conda init' before 'conda activate'
conda init
source ${miniconda_dir}/base/bin/activate base
conda activate tbp.monty
# success?

Hi @tristanls, yes, exactly that sequence. Miniconda is installed via homebrew: brew install miniconda

[tristanls]

Thank you for the confirmation, @d-led.

I did some research and found the following information in this Stack Overflow answer: https://stackoverflow.com/a/78502251:

(...)

Step 1

1.1 For Mac with Apple silicon chips(the M1/M2/M3-like chips),

if you are using default bash, you will need to run:

/opt/homebrew/anaconda3/bin/conda init

which will write necessary config in ~/.bash_profile file.

1.2 if you are using zsh, you will need to run:

/opt/homebrew/anaconda3/bin/conda init zsh

which will write necessary config in ~/.zshrc file.

1.3 if you are using an intel CPU Mac, you will need to change above path of anaconda to /usr/local/anaconda3/bin/conda.

Based on the above, I'm curious if you're using zsh, which would not be affected by running conda init alone but requires conda init zsh instead.

I'm considering including the instructions above on the getting started page, but I want to ask if you think this would address the problem you ran into.

[d-led]

I tried conda init zsh just now, and it did a global change just as the source command, and it changed the global shell appearance and paths -> not good:

(base) user@computer ~ % which python3
/opt/homebrew/Caskroom/miniconda/base/bin/python3

and without the init blob in .zshrc:

% which python3
/opt/homebrew/bin/python3

I'd not recommend messing with the global python due to its new idea of forcing virtual environments, e.g. via virtualenv in other contexts that don't use conda:

default new behavior:

% pip3 install zmq
error: externally-managed-environment

× This environment is externally managed
    Read more about this behavior here: <https://peps.python.org/pep-0668/>

under the globally modified shell:

 % pip3 install zmq
Requirement already satisfied: zmq in /opt/homebrew/Caskroom/miniconda/base/lib/python3.12/site-packages (0.0.0)
Requirement already satisfied: pyzmq in /opt/homebrew/Caskroom/miniconda/base/lib/python3.12/site-packages (from zmq) (26.2.0)

which works works but shouldn't, as the shell likely breaks other environments.

So, I'm torn. I'd go the manual way of sourcing the base environment before using. PyCharm did it automatically, by the way

[tristanls]

I found a setting that allows for opting out of the global change (https://stackoverflow.com/a/54560785):

conda config --set auto_activate_base false

With this, conda will no longer change the global shell when opening a new Terminal. Does that work for your setup?

Integrating the above, I think the new instructions are:

conda env create -f environment_arm64.yml --subdir=osx-64

Then one of conda init or conda init zsh, depending on the shell used. Followed by (with a note to omit if one wants conda always to activate the base environment):

conda config --set auto_activate_base false

And then:

conda activate tbp.monty