How can I have different 2.7.x versions in parallel on Windows? The installer overwrites older versions even if installed into a different directory.
Background:
I'd like to have more than one version of CPython 2.7 installed on a Windows machine for continuous integration purposes. I can do that without problems on Linux and OSX already.
Having different 2.x and 3.x versions in parallel works fine, but due to the longlivety of Python 2.7 (initial release in 2010) the 2.7.x versions aren't all that compatible among each other, and users don't update all that frequently.
After lots of searching I think it is safe to say that BrenBarn's comment answers it best:
Portable Python versions can be installed in parallel even if they have the same first two digits. The drawbacks are that the available versions lack behind quite a bit and there are only available in 32-bit (which makes perfect sense, they are made for portability after all).
I use the conda by Continuum Analytics to easily switch between Python versions
http://www.continuum.io/blog/conda
Related
It seems that many projects provide only an indication of the minor python version (e.g. python 3.6), whereas requirements.txt may require a specific version of a package (e.g. torch==0.4).
This specific version of a package is not available for any minor python version (e.g. torch==0.4 can be installed only with python 3.5 ou 3.6).
But what happens with maintenance Python versions? (e.g. python 3.6.9). Can we assume that torch==0.4 will always be distributed?
Python project distributions (libraries, packages, applications) are meant to be compatible with all maintenance releases of the same minor version of the Python interpreter (in 3.6.9: 3 stands for the major, 6 for the minor, and 9 for the maintenance or bugfix). In other words if a library is advertised as compatible with Python 3.6, it means it is compatible with all Python 3.6.* versions (3.6.0, 3.6.1, 3.6.9, etc.). On the other hand there is no guarantee it is compatible with 3.7.*, 3.5.*, or even less so with 2.* or 4.*.
I want to use PyPy with Python 2.6. The default version (PyPy 1.4.1) seems to be 2.5 when downloading binaries. Google doesn't seem to be helping much, advice?
You can download a nightly build if one exists for your platform. They support Python 2.7 and an official release with this support is supposed to happen in the next days, as PyPy developers are sprinting at PyCon right now.
Edit: As of 2012, PyPy stable releases support Python 2.7 and there is ongoing effort to support 3.x.
If you use an OS for which no nightlies are available, you can still build PyPy from source using latest code from Mercurial. You'll need a somewhat beefy machine for that and building on Windows (specially 64 bits) has a couple of hurdles to clear, so you might want to join #pypy in freenode if that is what you need.
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
I've been using MacPorts Python 2.6 on OS X 10.6.
I am considering also installing the Enthought Python Distribution (EPD) on the same machine because it comes preconfigured with matplotlib and other nice data analysis and visualization packages.
Can the two Python distributions co-exist peacefully on the same machine?
What potential problems will I have to look out for (e.g., environment variables)?
I know that building matplotlib through MacPorts is an option, but the process is lengthy (on the order of a full day) and there are open questions about compiling some dependencies on 64bit Intel.
I would like to know about the tradeoffs before committing to one of the two approaches.
I'm not an OSX user, so I can't say for certain, but you should be fine.
EPD bundles its own python interpreter and all required libraries. The installer basically just extracts a tarball into a stand-alone folder.
The linux installer doesn't modify any environment variables (not even $PATH), so I assume the mac installer is similar.
(Because of this, you'll probably want to manually set up aliases to the EPD python/ipython/etc binaries so you can more easily call them without changing your $PATH.)
EPD really should be completely stand-alone, as far as I know. It should be safe to install along-side anything else.
I've used EPD on Windows 7. It works great. Only stalled on me a couple of times with rather large data set.
I also use OSX, and was about to install EPD but hesitating a bit.
I think python 2.7.3 that comes with EPD (early 2013) will become the default python. Normally, upgrading to 2.7 from 2.6 should not be much of problem based on my personal experience. But I am a bit concerned to have 2 versions of 2.7 and what kind of impact it will have on using GAE SDK on my OSX. (Upgrading created a bit of hassle with GAE SKD.)
Here is what EPD readme says:
A full installation will install the following:
* Python framework -- installed into:
/Library/Frameworks/Python.framework/Versions/7.3
Python applications -- installed into
/Applications/Enthought
System fixes -- makes the EPD Python your default one by adding lines to
your .bash_profile to your path.
I think I will sleep on this.
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).