Is there an easy way to tell if a Python package will work if not matched to my Python release? For example, I cannot get PyGreSQL for Python 2.7 on Win (only 2.6) and I can't get ZODB for Win any more recent than Python 2.4. Does the version mismatch guarantee incompatibility, or do I just need to rename the package directory?
There's no way to tell for sure if the package will work on another Python version, but using older packages on newer Python 2.x's is much much more likely to work than the other way around.
One thing to watch out for: if you're installing a Windows kit, it may only install in the version it was meant for, due to registry look-ups and the like.
Related
Supposedly Python 2.7 is included native to OSX 10.8 and above (if I remember correctly), but I recently installed Python 3.5 to use for projects while I work through UDacity. Lo and behold, the UDacity courses seem to use 2.7 - wups! So instead of trying to uninstall 3.5 (this procedure seemed to scary for neophytes such as myself), I simply installed 2.7 in addition to the recently installed 3.5 and just run the 2.7 IDLE and Shell. Is this ok, or will I run into problems down the road?
I have installed two versions, 2.7, 3.4 and I do not have any problem by now. 3.4 I am using for my work project in eclipse environment, 2.7 for udacity course, like You ;).
As long as you keep your installation folders organized, you should have no issues having both on your computer, besides one thing. The path environment variable for python will determine which version is used by default, so I would say stick to one version, or make sure to make your programs as backwards compatible as possible. I have run into this issue on Windows, since I installed Python 3.4 before 2.7, and therefore to run older code, I have to manually select the python executable. In terms of libraries, I believe that for each python version, the libraries are completely separate, so you should be good there.
As others have said, if the installation directory is different it should be no problem at all.
One thing that'll make your life easier for switching between the two is to use an IDE such as PyCharm, you just have to change a drop down to switch between the two versions.
It should be fine. Its actually pretty common to have multiple Python environments. It helps to prevent dependency conflicts between your projects. That is what is happening when you are using tools like pyenv and virtualenv.
Using tools like pyenv and virtualenv may also help you with the path problems that others mentioned. They have commands to set up the path so that their version of pip, python, etc are used.
Im not sure about OSX, but with windows 10 my environment variables for 2.7 were overwritten with the 3.5 path. Not a tough fix, but a little confusing, since it was months later when I needed 2.7 again.
You can also use Anaconda for maintaining two versions of Python:
Download Anaconda for both Python versions
Open .bashrc
Add the path to new Anaconda you have installed for, e.g.:
export PATH="/home/paras/anaconda3/bin:$PATH"
Now there will be 2 export paths: one for Python 2 and one for Python 3. Comment the one which you don't want.
I have the same problem and it is not necessary to uninstall on version of python. Please take care to not mix them up - When you search them up on the start menu. You can make a desktop shortcut saying 2.6 and 3.5.
Hi
I just want to install mercurial but for all versions it needs python 2.6, I tried to use .rpm file but the only thing I got is lots of lines full of error which tells: need old versions before 2.6 and after 2.5 which is installed on my linux. any help would be appreciated.
Bests
Go to ActiveState and download their versions: https://www.activestate.com/activepython/downloads
It's much easier than using the .rpms.
Which distribution are you using? I would recommend you to upgrade your system to a newer version of your linux distro, whatever it is. Modern Linux distros are using at least python2.6 now.
If you do not want to upgrade your system with various reasons, ActiveState's python version as stated in Jasie's answer is good for your cause. It installs python in your system without breaking anything, just you have to add some lines in your .bashrc to force system find your ActiveState python installation before the system's python.
Another alternative would be installing earlier version of mercurial which supports the python version installed on your system. But I would not recommend you to do so..
Among these, my suggestion is upgrading your system to a merely "up-to-date" version, so that python2.6 or higher is installed on your system.
I have the default Python 2.6.1 installed as /usr/bin/python and Python 3.1.2 installed in /usr/local/bin/python3.1. Considering that I use only 3.x syntax, is it safe to replace the default interpreter (2.6) with the 3.1 one (python-config included) using symlinks (and removing old Python binary)? Or is the system relying on the 2.x version for some purpose I don't know?
If you're only using Python 3, start your scripts with:
#! /usr/bin/env python3.1
And you'll be using the right version, without doinking the system about.
edit: BTW this idea is suggested by the Python docs. Each script will be running the version of Python they depend on. Since Python 3 is not backward compatible, it seems dangerous to be replacing the Python executable with one that will break scripts other utilities may rely on.
You can not safely replace the system supplied python. I cannot find a Mac-specific reference for you... but some recent Python versions are not backwards compatible... Many scripts made dependent on an older version of Python will not run on an upgraded python. OS X Comes with Python pre-installed because it has dependencies on it.
Try using VirtualEnv instead.
Update: Just came across python-select from macports which may solve your problem.
Don't replace / remove any binaries unless you are in dire need for storage. In that case too, the mileage is very little in removing them.
You can simply make 3.1 as default with :
defaults write com.apple.versioner.python Version 3.1
There are other ways to ensure that you use 3.1 by default, I have not used them though.
export VERSIONER_PYTHON_VERSION=3.1
On Tiger, I used a custom python installation to evaluate newer versions and I did not have any problems with that*. Now Snow Leopard is a little more up-to-date and by default ships with
$ ls /System/Library/Frameworks/Python.framework/Versions/
2.3 2.5 2.6 #Current
What could be considered best practice? Using the python shipped with Mac OS X or a custom compiled version in, say $HOME.
Are there any advantages/disadvantages using the one option over the other?
My setup was fairly simple so far and looked like this: Custom compiled Python in $HOME and a $PATH that would look into $HOME/bin first, and subsequently would use my private Python version. Also $PYTHONPATH pointed to this local installation. This way, I did not need to sudo–install packages - virtualenv took care of the rest. Note: I liked this setup, so I'm just curious and thought I inquire the hive mind.
I guess it depends on your needs. Personally, I use the latest version for any series (2.5, 2.6, etc.) from MacPorts.
I compile it myself because this gives me the newest 64-bit version. The official OS X builds seem to be 32-bit only. I dropped MacPorts several months ago because its dependency system and its often outdated packages were too annoying.
The problem with using the Python version that's shipped with your OS is that it may contain bugs, or be limited in other ways. If you install Python from Fink or MacPorts, you have the liberty of updating it.
Another, important advantage of managing your own version of Python with a package manager (Fink or MacPorts) is that they help a lot with the compilation of module dependencies (for instance when you use a module that depends on compiled C code). Thus, installing Python modules is certainly easier if you do not use the Python shipped with OS X. This is an important point to consider, before making your choice.
What you do on your on machine is totally up to you. If you're going to deploy your code to other people's, I'd say it's clearly preferable to use the shipped version unless you really need the newer version.
I'm digging up this old topic.
There are no real answers to create your own python distro/framework from source and bundle and package it in a correct way. I tried to compile it from source, linking it against my C programmed application which uses python 3 and works on my computer. But when I move it around the filesystem (e.g to /tmp) it has hardcoded paths in the python compile. And I have no clue what script/wrapper to make.
My point to ship our own python distro is to make sure there is no oddness in interpeter change involved when shipping the application and rely on the OS python install.
It is also nowhere documented on the python docs.
I already found this post 4206511
Various software installations on my laptop each require their own particular version of Python. ViewVC requires Python 2.5 and Blender requires Python 2.6. Mercurial (thankfully) comes with its Python interpreter packaged in a DLL in the Mercurial installation itself.
How do I get by without having to install the entire Python environment each time? Is there some minimal installer which will install the bare minimum without affecting other programs? Can I modify the Blender and ViewVC installations so that they too use their own Python-in-a-DLL?
It's hard to know which "bare minimum" the Blender scripts you'll want to use in the future may be counting on (short of the full Python standard library, which isn't all that large in term of disk space after all). Why not install both Python 2.5 and 2.6? They can coexist nicely (if your scriptable apps use hashbangs like #!/usr/bin/env python instead of specifically mentioning python2.5 or python2.6, you may need to trick out their PATHs just a little bit).
You should be able to get away with installing the Python binaries in the same tree as the specific application I believe (Totally untested hunch though).