Pretty much this. Also US Govt and especially the millitary. When they buy "Linux" they buy RHEL. (Sometimes SUSE when they are working with Lockheed). Mostly because of support and RHEL5 and RHEL6 are certified with an alphabet soup of certifications (EAL4, FIPS-140-2, etc) and so that is what is used. Heck even RHEL7 doesn't have all those rubber stamp even though it is 2 years old almost now.
I don't do a lot of python anymore but we never depended on installed version. Everything was in an a virtual environment where we could control the libraries.
virtualenv doesn't manage different versions of the Python interpreter though. By default it uses the system Python. If you want another Python, then you need to install it yourself (somehow) and then point virtualenv at it. virtualenv is just a way to create separate bundles of libraries.
Re:From Python to Lua: Why We Switched
by BuckRogers on Wednesday January 27, 2016 @12:32AM
(#10978416)
It's for both libraries and different versions of Python. This is common and trivial.
I install specific versions of Python using the Deadsnakes PPA since I can easily pull in any version going back to 2.3 if I need. Or you can compile and install from source.
Then create a folder for your project, 'virtualenv -p /usr/bin/python3.5 venv' to create the venv in that directory. Activate/deactivate the environment as you wish when you want go between the system Python environment and the one in your folder.
I replied to @mrits because @mrits was presenting virtualenv as replacement for using pyinstaller to manage the installation of non-OS-managed Python versions (which @cowsandmilk was talking about).
I'm unsure how what I said:
> If you want another Python, then you need to install it yourself (somehow) and then point virtualenv at it.
Differs from what you are saying:
> 'virtualenv -p /usr/bin/python3.5 venv'
Re:From Python to Lua: Why We Switched
by creshal on Wednesday January 27, 2016 @03:50AM
(#10978996)
You can include the python interpreter inside the virtualenv. It's not entirely painfree (python and any pip packages are normally dynamically linked), but it works reasonably enough, especially when deploying it on the same OS version.
By default virtualenv links to the Python interpreter that you point it at (when you create your virtualenv). I'm unsure what method you would use to include the Python interpreter install in the virtualenv directory (other than creating a normal virtualenv, and then copying the files in after the fact).
virtualenv --always-copy
Re:From Python to Lua: Why We Switched
by Chris2048 on Wednesday January 27, 2016 @07:47AM
(#10979711)
I sometimes wonder if it's possible to use a gobo-linux style system, whereby the package manager just downloads the package to a versioned folder, possibly expanding it out, to a a package cache - then the venv need only symlink to it. The same could be done for python installs. Then do the same for the system python (e.g /bin/python points to /someplace/pyjunk/system/python, which in turn is a symlink to a particular interpreter, e.g. /someplace/pyjunk/interpreters/py2/2.7/cython_2.7_blub-i386/python).
Re:From Python to Lua: Why We Switched
by orthecreedence on Wednesday January 27, 2016 @01:50AM
(#10978655)
I never understood the fear of leaving the system's package manager's packages. Maybe I've been on Slackware too long, but compiling/installing packages from source is the norm. Also, package managers tend to ship with --enable-everything-everywhere-no-matter-what configure options. Compiling from source you can say yes, support libpng, no don't care about libjpeg etc and get a much leaner setup.
I know there's the argument that by straying you don't get security updates, but I can't really imagine Python 2.4 getting much security updates nowadays.
Re:From Python to Lua: Why We Switched
by greenleafjacob on Wednesday January 27, 2016 @02:36AM
(#10978790)
On the other hand, occasionally security updates will be surfaced as a patch file and you're waiting on the package managers. At least if you build it yourself you have the option of applying patches.
This is just an argument against bad package managers. Good ones will offer binary packages by default, but allow you to tweak (or just pass ./configure options to) an installation formula, at which point they'll switch over to pulling in the source package, applying your changes to it, building it, and installing the result, while still offering you full package-level management of the result (including having the package satisfy deps correctly.)
I never understood the fear of leaving the system's package manager's packages.
It's trivial when you have a handful of machines, all under your control. It's somewhat less trivial when you are dealing with 1000s of machines under the control of dozens of different people/departments.
My solution was to use pyinstaller[2] to basically ship my own python, first 2.7, and now 3.5.
[0] https://access.redhat.com/support/policy/updates/errata/#Lif...
[1] http://distrowatch.com/table.php?distribution=redhat
[2] http://www.pyinstaller.org