Question or issue on macOS:

1. Cask anaconda installs files under $ (brew -prefix). The presence of such files can cause warnings when running `brew doctor`, which is considered to be a bug in Homebrew Cask.
2. To avoid having to source thisroot.sh every time one needs to use ROOT, it is typical to add the instruction to.bashrc,.profile or analogous configuration files. Note, however, that sourcing thisroot.sh might interfere with ROOT versions installed with different methods. Install via a package manager. Supported by the community: these packages are not maintained by the ROOT team, but.

I have just got a new Macbook with OSX Sierra, so want to ensure my development environment is setup properly.

Nov 15, 2015 Installing on Mac with Brew, Dotfiles, Conda Nov 15, 2015 7 minute read. For now I'll make an analog version of a Dockerfile for a new MacBook setup- a blog post. Cask anaconda installs files under $(brew -prefix). The presence of such files can cause warnings when running `brew doctor`, which is considered. Brew suggests that you do not have any conda environments active when using the brew command, so I wrote a custom function that deactivates all conda environments before calling brew and reactivates them afterwards (see below).

I am looking to follow the ‘best practices’ mentioned here: https://github.com/nicolashery/mac-dev-setup

I need Python 2.x for work (urllib, Pandas, Numpy, Scikit-learn), and Python 3.x for some online classes (Pandas, Numpy, Django) I am taking.
I have installed Python 2 and 3, using brew install python and brew install python3 respectively.

However, on this link, there is no mention of Anaconda, just IPython.
Given that I already have Python 2 and 3 installed via Homebrew, is it even advisable to use anaconda, or should I stick to standard IPython as mentioned on the Github link above?
I am confused after reading this post: OS X – Deciding between anaconda and homebrew Python environments

If Brew and Anaconda can indeed work together, what specific steps can I take to ensure that there are no conflicts between the two versions?

How to solve this problem?

Solution no. 1:

brew and conda tend not to play nicely together, but I think I have a set up that has worked quite well for me so far. It was inspired by this post.

You can add the following code to your .zshrc:

You want to deactivate conda before running brew so that brew doesn’t find conda packages in your PATH whenever it tries to install something. In fact, brew doctor will complain if you have not deactivated conda before running brew, as mentioned in the post I link to above. (See also this question.)

One thing I should mention is that conda environments “stack”, but the brew() function I’ve written above does not keep track of your stack of environments. (See below for a version of this function that keeps track of this.) For example, if you do conda activate newenv while a conda environment oldenv is active, then conda deactivate will return you to oldenv. However, if you run brew using the function I’ve written above after activating oldenv and then newenv, running conda deactivate will not return you to oldenv but will deactivate your conda environments entirely.

This function also probably creates some unnecessary overhead when running brew, as I believe you only really need to deactivate your conda environment when running brew install. That said, if you’re the kind of person to care about that overhead enough, this answer probably doesn’t tell you anything you didn’t already know.

As a final note, brew cask install anaconda does not strike me as a good idea, since conda was designed to be installed in $HOME, but brew cask will want to install it in /usr/local, so that could lead to unpredictable behaviour.

Edit: Here’s is a version of the brew function which leaves your conda environments as it found it:

I’ve tested this in Zsh. I don’t think it will work in Bash. If you want to use it in Bash, you will need to change the for loop declaration to say something like for env in ${conda_envs[@]}. I haven’t tested this, however, so please test that it does what you need before use.

Solution no. 2:

I am new to python, and have had trouble with my python installation. I have both python installation from homebrew and anaconda on my mac. My anaconda installation had messed up my homebrew python dependency for vim and MacVim.

My solution is whenever I am installing/update package via homebrew I would remove anaconda from my PATH. This is a bit of a pain, but I only installing/updating package via homebrew once in a while so it okay.

To switch between python 2 and 3 here are my commands in Terminal:

I found this command from
How to change default Anaconda python environment
and
http://chris35wills.github.io/conda_python_version/

Also, here is a very good article on best practice on setting up python environment on mac
https://www.davidculley.com/installing-python-on-a-mac/

Solution no. 3:

Installing anaconda would mean you have no need of the system Python (leave it to the system, since you probably don't want to change it), or of Pythons installed by homebrew.

When you create a conda environment you can specify which version of Python you want it to use. For example:

Activating a conda environment (after the above command you'd do this with conda activate myenv, or source activate myenv for earlier versions) automatically means that the python command will run the Python interpreter you selected for that environment. Packages can be installed with pip as well as conda install, and are pretty much compatible with conda environments.

Brew Conda Pip

Solution no. 4:

You can set up a virtual environment (virtualenv) and assign different versions Python to each so there wouldn't be any overlap causing dependency issues.

Check out 'The Hitchhiker's Guide to Python' on how to walk through the setup.

Hope this helps!

Question or issue on macOS:

Sincerest apologies if this is easily found elsewhere, but although I found a number of posts with pyenv and Anaconda explanations, none addressed this issue specifically. However, I am often an idiot.

On Mac OSX (Mojave 10.14.6) I installed pyenv via Homebrew

brew install pyenv

And I happily install and switch between Python versions with

pyenv install …

and

pyenv global …

I typically use VS Code as my IDE.

I now have need to do some work in Anaconda. I haven’t used it before. Can I simply install Anaconda via the distribution site and use its navigator, and when I need my old python versions use pyenv and VS Code, or will there be a conflict when I install Anaconda? If there would be a conflict, is there a path to running both on OSX?

I could install it and see what happens of course, and restore from backup if it’s a big mess. But I’m hoping that a pyenv / Anaconda guru might have some sage words of advice that would save me potentially hours of cleaning up.

Thanks in advance!

How to solve this problem?

Solution no. 1:

There is a conflict, cause both pyenv and conda try to expose a global Python environment by default.

I’ve been using these tools together and best solution found by me is to

1. Alway initialize pyenv, use the Python set by pyenv global as the default Python
2. Only expose command conda but do NOT activate any environment from it

Detail

Since pyenv has been installed on your machine, you only need to install Anaconda.

Init conda without exposing the “base” environment from conda.

Done.

Note: After this setup, the default Python is the one set by pyenv global. Use pyenv and conda to manage environments separately.

Examples of managing virtual environments.

Default env location for pyenv is ~/.pyenv/versions.

Default env location for conda, check output from conda info.

Extended Readign

• Using Pip in a Conda Environment, very important

Solution no. 2:

Not super familiar with conda but I do use pyenv a lot. Mari silje samuelsen.

Pyenv has its own virtualenv manager that you can use. You can always check which virtualenv version is active with:

Brew Use Conda Python

You should see something like:

Where the * indicates the currently active virtualenv (this can be set using pyenv global like you mentioned). You can manually activate any virtualenv with:

Eg.

Then running pyenv versions gives:

Mac Install Miniconda

It’s generally a good idea to install any packages you want into a new virtualenv instead of the global virtualenv. It makes it easier to debug environment/dependency issues should you run into any.

Conda Brew Bar

Hope this helps!