How to/Should I install python 3.5 from 2.7? (windows) - python

I use python 2.7 and have the following packages installed:
distribute
decorator
*matplotlib
memory-profiler
networkx
*numpy
Pillow
pip
py2exe
PyAudio
*PyBluez
*pygame
pyglet
*PyInstaller
pyparsing
*pyserial
python-dateutil
pytz
pywin32
requests
scikit-learn
*scipy
setuptools
six
The ones marked with a * are critical.
I want to move to python 3.5, abandoning 2.7 completely (don't want to have both).
Can I do that while still keeping my old packages or do I have to install everything from scratch?
Are there any reasons I shouldn't move to py 3.5 from 2.7?
Should I move first to 3.3/3.4 or just straight to 3.5?
I'm not using a virtualenv because I'm not very familiar with that. Should I?
UPDATE: Follow-up.
I can just make a list of the packages I have and then manually install all of them.
How do I go about installing 3.5 and uninstalling 2.7?
Do I remove 2.7 first then install 3.5 or have them both simultaneously (will this create any issue?) then remove 2.7?
I mainly use python for numpy, bluetooth, serial, OpenCV, OpenGL. I intend to foray into a bit of web too later. I don't have any issue with syntax or method change. I was previously holding out for pyinstaller but that too has been recently ported to 3.5.

Just realized after switching.
Don't install python 3.5 if you want OpenCV to work. It's not yet built for that and some functions don't work.

You will need to reinstall all your packages. You should check that all those packages are available for Python 3. (From your question it sounds like you may have already done this, but not totally sure.)
It would be wise to test how things go with Python 3 before completely abandoning Python 2. You can do this by installing the two side-by-side, or by installing Python 3 in a virtual machine or some such thing. If you have existing code you want to keep using, you definitely want to test it to make sure everything runs smoothly on Python 3.
There is likely no reason to go to 3.3/3.4. Just go straight to 3.5.
Virtualenv can definitely be useful for setting up different Python environments on the same computer. However, you'll still need to install Python 3 before you can use it in a virtualenv.

Moving packages is bad idea, it is safier to reinstall them using pip:
Use pip freeze > requirements.txt. It will store all packages and versions in file
Install Python 3.5
Run pip install -r requirements.txt. It will install same packages on your python3.5
Run all tests against this Python to make sure your app still works as expected
The only reason to stay with 2.7 is incompatible code: if your code or one of your packages does not work on Py3K.
Virtualenv is useful tool, any python developer should know how to use it.

Related

What can I expect to change about how I write python on my Mac after I install conda?

Background
Currently, I have Python 2.7.17 and Python 3.8.1 installed on my Mac (v 10.14.6). Both Python versions were downloaded directly from Python.org using a "macOS 64-bit installer" .pkg file, in late 2019. Both were installed here:
python2: /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
python3: /Library/Frameworks/Python.framework/Versions/3.8/bin/python3
Currently, I use only pip (either pip2 or pip3, depending) to install python packages, which are saved here:
python2: /Library/Frameworks/Python.framework/Versions/X.X/lib/python2.7/site-packages
python3: /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages
I am about to begin an online course which requires that I install miniconda in order to install the packages that I need for the course. But after having a very bad experience having Anaconda installed on my machine years ago, and it taking me months to remove it and re-create a clean Python install, I am nervous. I don't want my machine to become a mess again, rife with error messages that it can't find this or that python version or this or that python library.
Question(s)
Assuming there will now be multiple installations of Python on my machine (in addition to the versions that I already have, since I believe yet another version of python is installed along with conda), and there will be new places where python packages will be saved, what can I expect to change about how I write python after I install miniconda?
Is there anything I will need to do differently from what I am doing now when I write python code?
How can I ensure that everything remains working and compatible and I avoid the fate I suffered many years ago?
Happy to edit/clarify this question per user suggestions. Thanks!
Use conda environments and install Python into those environments. This ignores, by design, the versions of Python that are installed at the system level. Also, what's installed into environments (other than the one you're in) is ignored. As somebody who uses conda for all Python development, I don't even know what I have installed in /usr/local/bin/ or other places. Everything is in /path/to/miniconda3/envs/env_name_n. You don't have to uninstall other versions of Python you have elsewhere; the point of environments is to keep everything isolated.
What can I expect to change about how I write python after I install miniconda?
Is there anything I will need to do differently from what I am doing now when I write python code?
Use conda environments and use conda as your package manager. For almost every major project, it nearly a drop-in replacement for pip. Outside of managing dependencies, not much changes.

So many pythons, which do I need?

It seems I have several Python versions installed on my Mac (High Sierra). Do I really need more than one each of Python 2.7 and the most recent Python3?
I am primarily concerned about confusion when adding modules to the environments.
Here are the python executables I can find, excluding symlinks. Do I need them all? Does Apple need one version just for the OS? (Maybe that's Ruby I'm thinking of._)
/usr/bin/python
/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/bin/python
/usr/local/Cellar/python/2.7.13/bin/python
/usr/local/Cellar/python/2.7.13/share/python
/usr/local/Cellar/python/3.7.1/libexec/bin/python
On MacOS, you need to have the system-installed Python 2 in /usr/bin/python because some system functionality depends on it.
If you have other versions installed via Homebrew or etc, that's strictly optional. For developing code in Python, definitely install a recent version of Python 3; you should not be developing new code in the legacy version 2. It will run out of support in a year or so, and many important third-party libraries etc have already abandoned support for it.
If you do need to maintain Python 2 code, having a Homebrew version of the most recent Python 2.7.13 is probably a good idea. The system /usr/bin/python is at version 2.7.10 as of MacOS Mojave; and if we extrapolate from Apple's update policy history for third-party open-source software in the system, it will probably remain there for many years.
Homebrew is just one of many ways to install additional Python versions, but since this is what you seem to be using already (as indicated by the /usr/local/Cellar paths) I will not go into alternatives.
For switching between versions, virtualenv is the common baseline, though there are many add-ons like pyenv etc which add convenience features or alternative models for switching between projects which require different versions of Python and various packages.
Note: this answer might be primarily based opinioned.
First, in macos, I encourage you to use brew to install python. So, if you want to instal Python 3 run:
$ brew install python
Probably it is already installed, so to update it run:
$ brew upgrade python
This will upgrade to the latest version of Python 3. In general, if you start a new project you should use Python 3. Remember that Python 2 will be deprecated at the end of this year 2019.
Second, I highly recommend you to use virtual environments to avoid having issues with dependencies. You can create a virtual environment running:
$ python3 -m venv .ven
This will create a virtual environment in .venv in your current working directory.
As an alternative you can use pipenv to track dependencies too which I also encourage you to install using brew.
$ brew install pipenv
Then you create a virtual environment running:
$ pipenv --three
Keep in mind that you will have two versions of Python in your machine python which is Python 2 (installed by default in your machine) and python3 which is Python 3. Then, if you want to run Python 2 just type python, while if you want to run Python 3 type python3.
Finally, you can also keep track of several python versions using pyenv. This is very useful if you need to use multiple versions of Python for example Python 3.1, 3.2, 3.3..., 3.6, 3.7.1, 3.7.2, 3.7.3, etc.
This is what has been useful in my experience using macOS. You could also use Docker to completely isolate your environment, but probably the first two points is enough if you are a beginner.
While Python 3.x is what python solutions should be implemented in today, many existing python applications, modules, etc, are implemented and maintained in 2.7 or lower. Sometimes you'll find multiple versions of python on your computer because applications you've downloaded in the past had you install them so their application would work properly on your machine. As long as you don't want, or need applications that may depend on past versions of python, you can update to the latest one and delete the old versions.
If you are planning on developing in python, and you can use the latest version, you should definitely do so. If you rid of the versions of python on your machine, applications, modules/scripts, etc may not work or function properly.
Python comes pre-installed on Mac OS X, but it is not required to be on your machine for your computer to function, just the applications that may be on your machine that may use Python.

What to do after upgrading from Python 2 to Python 3?

Recently I've installed Python 3 after using 2 for quite a while, so I have many libraries for Python that I've installed using pip. I've already started using the symlink python3, but what else do I need to do to change over?
For example, while I have made the alias python=python3, I don't know about the modules I've installed with pip. I was using a version of pip for Python 2, but does that mean modules were written for Python 2 and not 3? Do I now need to start using pip3 (or make a corresponding alias pip=pip3 or pip=pip3.5)? If modules were installed using the command pip, does that mean I have to reinstall them for Python 3 using pip3? If I do need to reinstall them for 3, should I start removing them from my Python 2 env as cleanup?
And another question that seems like it may entail a lot of work: How should I change all my virtual environments for Python projects? They were all Python 2 envs, and now I'm not sure whether it's necessary, useful, or possible to reinstall or upgrade the modules within them to the corresponding ones for Python 3.
Sorry if this seems like a duplicate question - I've searched and only found resources regarding "how to upgrade" rather than "what to do after upgrading". Thanks for your help!
It is strongly recommended not to symlink python to Python 3, at least on Debian-based Linux distros. Debian utility scripts use both Python 3 and 2.7 to work (which means you already had a copy of Python 3 somewhere...), and as a consequence Debian-based distributions ship both versions. Symlinking can cause unexpected breakages. This may or may not be true on other systems, however, but with such ambiguity it is probably useful not to try.
Instead, live with symlinking python3 to Python 3. Leave python alone.
pip is usually symlinked to the corresponding pip program for 2.7. Use pip3 to specify you want to use the pip program for Python 3. If you use pip, you'll find modules for Python 3 being installed to Python 2.7 site directories and nothing will work as you expect it to. There should be no reason why you can't symlink pip to pip3, but I'd still not recommend it - it's better to tread cautiously in this regard.
You don't need to change your current virtual environments. Just create new ones with virtualenv, pointing to the correct Python program to use. This is the whole point of virtual environments: to sandbox different Python versions, so that neither of them adversely interact with each other.
If you have projects you really want to ship to Python 3, I'd recommend using a version control system to back up your current files, and then reproducing them in a new virtual environment configured for Python 3. This is quick, simple and painless.

How to upgrade Python along with installed packages?

If I install several packages with Python 2.6 (e.g. using easy_install) and then I want to upgrade to Python 2.7, is there a way to upgrade Python and then automatically "import" all those installed packages along with it? Or do they have to be reinstalled?
Two related questions: (1) if a package is installed in a Python 2.6 packages directory, is it legitimate to import it into the PYTHONPATH of a newer Python, like Python 2.7, or must all the packages be reinstalled with Python 2.7? (2) if I use easy_install, how can I tell it to use the newer Python? E.g. 2.7 instead of 2.6? Or should I just reinstall easy_install using Python 2.7 to do this? thanks.
First, this is one of the many reasons you want to use pip instead of easy_install. (You still need easy_install to get pip itself, but beyond that, don't touch it ever again.) If you'd used pip, you could just do this:
pip freeze > modules.dump
That gives you a list of all of the modules you have installed, and their version numbers. Most of the time, you can just take the list of modules (line.split('==')[0] for line in f) and pass it to pip install.
But that's for future reference. For today, you have to piece it together yourself by looking through your site-packages directory. Fortunately, many things will end up as foo_bar-1.2.3.4-blah-blah.egg, so all you have to do is guess whether the package is named foo-bar or foo_bar at PyPI, and usually even if you guess wrong, easy_install or pip will get the right thing anyway. So, you can't quite automate it, but you can get close.
But yes, however you do it, you do need to reinstall. Anything that requires C extension code has to be recompiled. Pure-Python packages may not need to be changed, but they may, and you're better safe than sorry. Also, if you try to copy some things over but not others, you're going to make a big mess of your dependencies.
(1) if a package is installed in a Python 2.6 packages directory, is it legitimate to import it into the PYTHONPATH of a newer Python, like Python 2.7, or must all the packages be reinstalled with Python 2.7?
Don't do that; reinstall them, as explained above.
(2) if I use easy_install, how can I tell it to use the newer Python? E.g. 2.7 instead of 2.6? Or should I just reinstall easy_install using Python 2.7 to do this? thanks.
You need the 2.7 easy_install. You can usually use a 2.7 easy_install with 2.6 by running, e.g., python2.6 $(which easy_install), but the other way around isn't guaranteed to work.
And you don't want to do that anyway. If you want two versions of Python in parallel, you want two versions of easy_install—normally you want to end up with easy_install-2.6 and easy_install-2.7, with easy_install as a symlink to whichever one you consider your "primary" python.

Installing rpy or rpy2 on mac

I'm in the process of trying to install rpy or rpy2 on my Macbook so I can use R from python. Information about rpy can be found here: http://rpy.sourceforge.net/index.html
My problem is in the installation itself. I can't seem to make python recognize Rpy using import command: I keep getting the message "No module named rpy2". Does anyone know where I can find some step-by-step instructions on how to successfully install this? I have already installed both python and R, and both are working perfectly. Thanks in advance!
Try easy_install rpy2. You need to install easy_install before that.
I took that from here
I long gave up on these issues on my Mac. Since I installed OS Lion, I found that I needed to switch to MacPorts and then installing packages like RPy2 from their repository.
I know some people like to dig into the system and learn all the idiosyncrasies of the architecture and keep a vanilla install of python on their Mac. I find that i get problems like yours too frequently and they distract me from real work.
I just download the MacPorts modules when I need them and get on with the problem at hand. Others say the same thing about HomeBrew but I have only worked with MacPorts and it makes installation of modules too easy. You may want to invest some time investigating if either of these solutions work for you.
Another approach to using package managers like MacPorts or HomeBrew is to use a virtualenv and install python and all related modules there. Again, not a solution I have tried directly, but a quick search will show you many endorsements for this approach to using a specific Python executable and packaging its modules In an isolated environment.
as long as you have pip installed on your mac, then life will be easy as:
sudo pip install rpy2
If you want rpy it isn't on macport, at least a search of their packages only showed rpy2. According to the rpy web site its in fink. However at the moment fink is down so I can't verify this. Which is irritating because I need rpy (not rpy2) because another package has a dependency on it.
I also tried pip to find rpy and it said no package, which is a shame because pip is great for python installs (provided I remember to use 'sudo' first.

Categories