Several newbie questions about coexistence of Homebrew and pyenv on MacOSX Yosemite. These are the things that I am still confused about after applying my level of google-fu to the subject. Sorry for the length, but I wanted to be as clear as possible.
First, some background. I used brew to install pyenv, then pyenv to install python2 and python3.
brew install pyenv
brew install pyenv-virtualenv
*I also added the necessary hooks into my profiles.*
pyenv install 2.7.10
pyenv install 3.4.3
pyenv rehash
pyenv global 2.7.10
??? Question (or clarification). If brew is using a python installed by pyenv, I assume that this is frowned on because brewed packages would be built with a dependency on something outside of brew (e.g. using pyenv to uninstall a python version could break brewed packages)? It appears that brew uses whichever python comes first in the PATH (currently pyenv's version for me)? However, in each of the below cases the shims are for “python” rather than “python3” (even for pyenv 3.4.3). Am I correct then in assuming that setting “pyenv shell 3.4.3” will make brew link python commands (that it assumes are for python2.x) to pyenv’s python 3.4.3, which I guess would tend to mess things up?
pyenv shell 2.7.10
brew --config
Python: /Users/anonymous/.pyenv/shims/python => /Users/anonymous/.pyenv/versions/2.7.10/bin/python2.7
pyenv shell 3.4.3
brew --config
Python: /Users/anonymous/.pyenv/shims/python => /Users/anonymous/.pyenv/versions/3.4.3/bin/python3.4
pyenv shell system
brew --config
Python: /Users/anonymous/.pyenv/shims/python => /usr/bin/python
??? Question. If using pyenv’s pythons to brew with is a bad idea, then should I also install brewed versions of python and python3, or would this conflict and cause problems in some way? My options seem to be either use the system python that came installed on my Mac, or use brew’s own pythons for all my brewing needs. In the first case, I could just make sure to call “pyenv shell system” before any brewing, or set some alias to automate this as others have suggested (alias brew="env PATH=${PATH//$(pyenv root)/shims:/} brew"). However, this means I have to use the rather outdated system python. If instead I were to also use brew to install python2 and python3, would this conflict with versions installed using pyenv in any way, or will brew’s pythons live happily completely separate from pyenv’s (I think this is true, but I want to double check before I try it)? Would this give me a setup where all my brewing used brew’s python or python3 (I assume I still need an alias such as that above to make sure pyenv’s versions are not found first in my PATH), and everything else outside of brew would use pyenv’s pythons? Is this a bad idea for any reason?
pyenv global system
*Add to profile:*
alias brew="env PATH=${PATH//$(pyenv root)\/shims:/} brew"
brew install python
brew install python3
??? For example, consider the scenario where I want to use brew to install boost-python with python3 bindings. Does this require a brewed python3 version, and will it subsequently work for a different pyenv version of python 3.x? If I only have pyenv’s versions installed, does the --with-python3 flag even work in this case? On the other hand, if I have brew’s python3 installed in addition to pyenv’s, I assume --with-python3 will link against brew’s python3 (with above alias). If so, will boost-python even be usable when called from a python session running pyenv’s version (not sure if this is more appropriate as a question about boost-python itself), or is this completely fine?
brew install boost
brew install boost-python --with-python3
??? Opinions regarding symlinks for brew that point to pyenv python's? Another post suggested symlinking pyenv's pythons so brew can find them. Besides the obvious caveat that brew now depends on python's that it does not itself manage, is there anything horribly wrong with this idea?
ln -s $(brew --cellar) ~/.pyenv/versions
I'll try to answer each of your questions.
1 Does brew "frown" upon using pyenv's Python rather than brew's?
In short, yes. They lay out the whole story here, and in short you're on your own to manage issue that come up.
2 Will brew Python and pyenv Python conflict?
No. As Tim Smith says in another answer, "nothing bad should happen if you do". Use your PATH to manage which Python you (or an application) sees (and this is what pyenv does).
3 Packages with Python dependency satisfied by brew Python working with "oustide" Python from pyenv
As Tim said, this shouldn't be a problem.
4 Use symlinks so that we only use pyenv Python?
I think you're referring to this post, and it's a fun idea, but likely perilous for maintenance. Fwiw, I'm doing this now.
I lay out how to do it here.
A clarification: Homebrew uses system Python whenever it doesn't make a difference exactly which Python 2.7 it uses (which is pretty common). If you build something --with-python, that will use the first Python in PATH, if that Python is Python 2.7. Otherwise, Homebrew will install and use Homebrew python.
I would not expect that you will find it necessary to install Homebrew's python and python3 but nothing bad should happen if you do. Note that if you use pip or easy_install to install a package that installs scripts (like ipython), those scripts are written so that the package will always be invoked with the python against which it was installed. (You can always get around this behavior by running packages like python -m ipython.) Otherwise, you can control which python you're using just by setting $PATH.
Building boost-python against whatever python 3.4 will work with any other python 3.4. It will probably not work with python 3.5. (This used to be more complicated, but it isn't, anymore!)
Symlinking your pyenv pythons into /usr/local shouldn't hurt but doesn't do anything except put them in $PATH; it won't help Homebrew find them otherwise.
Related
I installed python3 using homebrew, but I stumbled upon many posts mentioning that it is better to use pyenv to manage different python versions. However, I have not found a post that answers my question:
Should I uninstall python3, install pyenv, and then reinstall python3 using pyenv? Or should I just install pyenv now, would this work?
Below is output from terminal:
System python
python --version
Python 2.7.18
which python
/usr/bin/python
Python3
python3 --version
Python 3.9.10
which python3
/opt/homebrew/bin/python3
From https://justinmayer.com/posts/homebrew-python-is-not-for-you/
Homebrew’s Python is not for you. It exists to serve Homebrew, or more accurately, Homebrew’s other formulae. The primary purpose of Homebrew’s Python formula is to enable other Python-dependent Homebrew packages to work. If installing Homebrew’s Python allows you to run the occasional Python script or access the REPL, that’s a nice side benefit, but anything beyond that — including developing software with Python — is squarely out-of-scope.
You can run brew uses --installed python to check if any installed packages depend on Homebrew Python. If no packages are listed, then you can safely uninstall via brew uninstall python and use pyenv instead.
I used to have python and python3 installed. So I could decide which python to use. I now updated python with homebrew and it migrated python3 to python. How do I run python2 now?
When I check the installation I get:
$ python -V
Python 3.6.4
$ python2 -V
-bash: python2: command not found
$ python3 -V
Python 3.6.4
If I try to simply reinstall python2 I get:
$ brew install python2
Warning: python#2 2.7.14_1 is already installed
However I cannot use python2.
python2: command not found
You're missing the symbolic link that Homebrew makes from the Cellar to the actual bin directory on your path.
Use:
brew link python2
to fix that.
You may run into a warning:
Warning: python#2 is keg-only and must be linked with --force Note that doing so can interfere with building software.
See the accepted answer to this SO question for some details on that.
In most case, you can then safely use
brew link --force python2
if you're not planning building your own libraries that require the source code (libpython.so and Python.h) for Python 2.
If you do require the source code, you'll need to provide the include paths and library paths to e.g. /usr/local/Cellar/python/2.7.14_3/Frameworks/Python.framework/Versions/2.7/include/python2.7 and /usr/local/Cellar/python/2.7.14_3/Frameworks/Python.framework/Versions/2.7/lib/. But that's a different topic or question.
To use pip for Homebrew's Python 2, best to use is
python2 -m pip <command>
Then you can clearly see what Python your pip command goes with, and keep it apart from Python 3 (which would be python3 -m pip).
Note
If you have Homebrew problems, first cause of action is to run
brew doctor
The error messages are usually quite helpful to fix at some of the problems.
It seems that Homebrew has changed things again - as I had both python 2.7.x and 3.x.x installed through Homebrew for the same reasons. After the initial update, python2 would no longer work, but if you used python#2 you would get access as before.
Now however, they have seemed to partially revert some of these changes. Calling python now points to the keg-only 2.7.x homebrew installation instead of the 3.x.x installation. In addition, python#2 no longer works, but python2 no does. python3 still points to the 3.x.x installation as before.
[NOTE: I have not modified my ~/.bash_profile for any of these changes to occur.]
I need to work with Both Python 2.7.12 and python 3.5.2 simultaneously on my Ubuntu 16.04.1 LTS. Python 3 came pre-installed so I've no idea where it sits, in terms of path to the directory, while python 2 sits in /usr/local/lib/python2.7/.
I found lots of questions on SO and on askubuntu about how to install but nothing about how to use them separately, installing different libraries, and what should I avoid or be careful of, if I maintain this dual python thing for the long term? For example, I usually run pip install to install a library and I can check that its installed in my python2 directory but how do I install the same package for my python3 without conflicts? Something like: python3 pip install <package> ?? Where is the default python3 installed? And how do I call python3 for paths where python is not part of the command for example: pip freeze, sudo-apt get, etc.?
PS: I've not officially worked with Virtualenv but I've been informed that is usually good for isolating projects within a python language version, rather than isolating two different language versions from each other.
Please let me know.
Thanks
This is absolutely no problem, as Python does that for you. You don't need a virtualenv at all.
If you use Ubuntu packages, make sure you use the python3- versions for Python 3, and the normal python- versions for Python 2.
For example, python3-numpy and python-numpy.
If you use pip to install extra packages, you an either use the pip script with the version number appended: pip2.7 or pip3.5, or, my preferred method, call pip as a module for the respective Python executable:
python2.7 -m pip install <whatever>
and
python3.5 -m pip install <whatever>
Other than that, there should not be any issue: Python stores the packages in completely separate directories, and each Python executable only uses its respective directive.
Do not fiddle around with PYTHONPATH, unless you really know what you're doing. This has the danger of setting your PYTHONPATH to a directory with Python 2.7 modules and then using Python 3.5 to run things.
If you start from scratch, you may need to install pip first.
For the system Python(s), use the relevant package:
sudo apt install python-pip
sudo apt install python3-pip
For your locally installed Python(s), use the built-in bootstrapper module:
pythonx.y -m ensurepip
Note on the OS-installed Python executables:
Python 3.5 lives at /usr/bin/python3.5, Python 2.7 (the OS one) at /usr/bin/python2.7.
You could even use the OS 2.7 one next to your locally installed /usr/local/bin/python2.7 (and confuse yourself when a package can't be found because you used the wrong one).
Or install Python 3.6 next to Python 3.5 (provided you've used make altinstall, so python3 doesn't get overwritten).
This is also why you don't really want to run pip (or even pip2.7) as is: pip2.7 may get you the system one, instead of the one in /usr/local/bin/pip2.7, depending on your PATH.
(The same goes for the python2.7 executable, so if you need to specify the full path /usr/local/bin/python2.7 to run that one (or have an alias), the same holds for pip2.7. If, on the other hand, /usr/local/bin is first on your PATH, you should in principle never run into the same pip and python executables.)
My programming literacy is very basic, but I like programming and I have been taking some MOOC's to bring me into the 21st century.
I started off by taking a course in Python and installed 2.7.11 (from https://www.python.org/downloads/), now I am onto another course that requires Python 3.x
Can I simply install Python 3.x alongside the 2.x version (on my Mac)? Or, will that create all kinds of conflicts and problems? To add to the picture, I am just using the IDLE that comes along with the download.
If the solution involves a bunch of terminal line commands, or coordinating 3 additional downloads of other packages to make it happen, it is already out of my league. Like I said, I am coming into this as nearly a complete novice.
Thanks for you help.
This might help anyone having Error: python 2.7.14 is already installed when trying to install python3 with brew install python3. Due to python2.7 being retired on 2020, python3 is now the same as python and python2 is python#2.
To fix the error, just run brew upgrade python and if you still want python2 you can install it by brew install python2. In my case I did not have to run the final command and I had both python installed.
It shouldn't create any conflicts simply install python3 with brew install python3, also you get more info for doing it correctly in What is the correct way to install python on OS X? question.
NOTE: After installing python3 you would have two python interpreters python3 and python2.7, your python points to python2.7 as long as you don't change it, in other words your default python interpreter is python2.7 and do not change it without serious reason for that.
To run python3 scripts execute them with your python3 interpreter, tools like pip, easy_install, virtualenv for python3 shall be installed with that interpreter (python3).
You might want to look into pyenv: "pyenv lets you easily switch between multiple versions of Python". Also install-able with brew install pyenv
If you like programming you had better get used to doing a bit of setup and juggling of downloads. If you are going to do much python for different projects you would do well to understand virtualenv's before you find your projects' requirements conflicting.
I went thought and installed pip and then added a bunch of libraries that I like to use and then, only after installing everything, did I realize that everything went into the 2.7.2 sit-packages directory, so the Python2.7.5 version doesn't see anything.
Now, If I type python --version in the terminal, the correct version is started. However, pip is still "tied" to the default version of Python.
How do I go about telling OSX to look at the new version of Python for everything?
Honestly, one way around this is to make sure that virtualenv works with the right version, and just use pip inside the virtualenv.
A common pattern of Python installation on the mac is to use Home Brew which is a package manager for the mac. You can then install python using:
sudo brew update
brew install python
Provided you have the XCode command line tools already installed.
After I think that the Home Brew Python will be the first in the path. If this is not the case, it might be simpler to use a virtualenv by installing the package with the pip provided by the Mac Brew install (/usr/local/Cellar/python/2.7.5/bin/pip).
After this is done you need to create a virtualenv
virtualenv ~/path/to/the/env
and to activate it
source ~/path/to/the/env/bin/activate
This will be a brand new python and your path will be configured correctly (the python and the pip will be the right ones). You can always delete it, deactivate it or source it as needed.