Homebrew-cask: brew cask install miniconda: PATH of all binaries not set

[gbstan]

General troubleshooting steps

• [x] I understand that if I ignore these instructions, my issue may be closed without review.
• [ ] I have retried my command with --force.
• [ ] I ran brew update-reset && brew update and retried my command.
• [x] I ran brew doctor, fixed as many issues as possible and retried my command.
• [x] I have checked the instructions for reporting bugs.
• [x] I made doubly sure this is not a checksum does not match error.

Description of issue

Installing miniconda with brew cask works. However, the binaries installed subsequently by conda are not available directly as the PATH variable is not set.

Command that failed

conda install jupyter lab -> works as expected
jupyter lab -> doesn't work!
-bash: jupyter: command not found
export PATH=/usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin:$PATH
jupyter lab -> works correctly!

However, this is problematic for 2 reasons:
1) The need to set the PATH variable manually is currently not explained when installing minconda with brew cask
2) There is no alias provided either and thus adding "/usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin" to the PATH will break at the next update of miniconda (e.g. when miniconda upgrade from 4.6.14 to 4.6.15)

[CircleOnCircles]

I am not sure if you had activated the environment or not.

The thing is if you are using pyenv poetry pipenv other python package managements, they will not work correctly. Thus, explicitly activate is the way out.

I would argue for the fact that the command to activate

conda activate -> doesn't work out of the box

[CircleOnCircles]

I believe that adding a note is the best way to deal with this.

It allows users to rethink about the right order of PATH given that they use more than one python package/environment management.

[gbstan]

I suppose adding a note could be useful. But still, if users are asked to manually update their PATH variable (in .bashrc or .zshrc or ...), it looks odd to me that the PATH is not generic. In the case of miniconda, the path where the binaries are is: /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin.

This path is not a generic path and contains the version number, i.e. "4.6.14". It seems to me something is missing in terms of aliases to make the PATH modification more generic.

[CircleOnCircles]

I suppose adding a note could be useful. But still, if users are asked to manually update their PATH variable (in .bashrc or .zshrc or ...), it looks odd to me that the PATH is not generic. In the case of miniconda, the path where the binaries are is: /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin.

This path is not a generic path and contains the version number, i.e. "4.6.14". It seems to me something is missing in terms of aliases to make the PATH modification more generic.

About 'generic path',
I think. It is the upstream's decision to make it generic or not generic(alias).

Anyway, there is a pull request #66544 to modify the path to the 'generic' one.

[xyu]

if users are asked to manually update their PATH variable (in .bashrc or .zshrc or ...), it looks odd to me that the PATH is not generic. In the case of miniconda, the path where the binaries are is: /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin.

👋 author of #66544 here, (also the previous #65618 which caused the path to be so messy as well,) and yup hopefully the change to make the base PATH to miniconda to /usr/local/Caskroom/miniconda/base gets accepted so it's less messy.

But regarding PATH in general we should not ask anyone to change PATH because that's handled internally by conda itself. More specifically the bin dir that's within the miniconda package should never be set in your PATH manually as that may override existing system python versions and cause all sorts of oddities. Once miniconda is installed via brew cask the conda executable will be available at which point conda init should be run so that conda can setup its own environment for the shell that you are using (e.g. bash, zsh, etc.) I think this is what conda activate prompts the user to do when it's run without first having conda init run.

tldr; the proper "conda" way to use miniconda to manage your Python environment should be something like:

Initial install

$ brew install miniconda
...
$ conda init zsh # if you are using zsh, otherwise use your shell
...

Using conda

$ conda install jupyter # this installs into base env
...
$ jupyter lab # this should work after starting a new shell post conda init because conda auto activates base env
...

[gbstan]

Running conda init did indeed solve the problem.
However, brew doctor now gives this:

Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and which additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew-provided
script of the same name. We found the following "config" scripts:
  /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin/freetype-config
  /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin/libpng16-config
  /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin/python3.7-config
  /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin/libpng-config
  /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin/xml2-config
  /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin/python3.7m-config
  /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin/python3-config
  /usr/local/Caskroom/miniconda/4.6.14/miniconda3/bin/ncursesw6-config

Is there a way to fix this?

[xyu]

@gbstan conda works by modifying the current running / working environment so these warnings are expected because conda adds itself to PATH. Running conda deactivate then brew doctor will show that these warnings go away once conda has been deactivated. Basically in order to have a working and activated conda env these config scripts must be in PATH.

[gbstan]

Ok. Thanks. I will ignore these messages then as this seems to be normal.

[vitorgalvao]

$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!