Michael Sarahan
2 min readJun 19, 2019

--

Hello from the Anaconda team, and thanks for writing this up. I wanted to point out a couple of small issues here that would be good to clarify:

In your two examples of running installers, you have a .pkg installer for the python 2.7 example:

bash ~/Downloads/Anaconda2-2019.03-MacOSX-x86_64.pkg

That should be the .sh file. The .pkg installers are GUI things. It’s user preference, but I find the .sh installers to be much more straightforward.

Next, we really don’t recommend modifying PATH. That’s the old way of doing things. By far, the most common reason why people see problems is just that they aren’t refreshing their shell session. You do tell them to restart their terminal, but if people forget that, they may see this error. It may be worth reminding people in huge font, with bold text, and maybe red letters, that if they see “command not found” problems, they should first try closing and reopening their terminal. Then, and only then, should they proceed with troubleshooting.

Modifying PATH can cause problems if there are any other programs on your system that have the same names, that Anaconda then hides (shadows) by being found first. What “conda init” does is to set up a conda “shell function” and keep the other stuff off PATH. Nothing but conda is on PATH. It then defaults to activating your base environment at startup. The net effect is very much like your PATH addition, but has some subtle, but critically important differences:

  1. activation ensures that anaconda’s PATH stuff is right up front. Putting anaconda at the front of PATH permanently is good in that it prevents confusion, but bad in that it shadows other stuff and can break things. Activation is a less permanent way to do this. You can turn off the automatic activation of the base environment using the “auto_activate_base” condarc setting.
  2. activation does a bit more than just modifying PATH. It also sources any activate.d scripts, which may set additional environment variables. Some things, such as GDAL, require these. These packages will not work without activation.

So, rather than your tip on modifying PATH, what we recommend is following the directions at the end of the installer, should you choose not to run conda init:

You have chosen to not have conda modify your shell scripts at all.
To activate conda’s base environment in your current shell session:

eval “$(/home/msarahan/mc3_dummy/bin/conda shell.YOUR_SHELL_NAME hook)”

To install conda’s shell functions for easier access, first activate, then:

conda init

If you’d prefer that conda’s base environment not be activated on startup,
set the auto_activate_base parameter to false:

conda config — set auto_activate_base false

so that will look like 2 commands:

  1. eval “$(/home/msarahan/mc3_dummy/bin/conda shell.bash hook)”
  2. conda init

Note that in step 1, I changed the shell name from YOUR_SHELL_NAME to bash. You may need to adjust that yourself to your shell.

--

--