4 ms·

I have customers that use RHEL 5 still (supported until 2017 or 2020 in the extreme), which ships with python 2.4 as the system python[1]. My solution was to u

I have customers that use RHEL 5 still (supported until 2017 or 2020 in the extreme), which ships with python 2.4 as the system python[1]. 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/#Life_Cycle_Dates https://access.redhat.com/support/policy/updates/errata/#Lif... [1] http://distrowatch.com/table.php?distribution=redhat http://distrowatch.com/table.php?distribution=redhat [2] http://www.pyinstaller.org http://www.pyinstaller.org

mrits 11y ago
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.
- pyre 11y ago
  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.
  - BuckRogers 11y ago
    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.
    - pyre 11y ago
      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'
  - creshal 11y ago
    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.
    - pyre 11y ago
      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).
      - creshal 11y ago
        virtualenv --always-copy
  - Chris2048 11y ago
    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).
rdtsc 11y ago
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.
orthecreedence 11y ago
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.
- greenleafjacob 11y ago
  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.
  - derefr 11y ago
    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.)
- deleted 11y ago
  [deleted]
- dagw 11y ago
  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.

mrits 11y ago

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.

pyre 11y ago
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.
- BuckRogers 11y ago
  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.
  - pyre 11y ago
    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'
- creshal 11y ago
  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.
  - pyre 11y ago
    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).
    - creshal 11y ago
      virtualenv --always-copy
- Chris2048 11y ago
  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).

rdtsc 11y ago

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.

orthecreedence 11y ago

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.

greenleafjacob 11y ago
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.
- derefr 11y ago
  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.)
deleted 11y ago
[deleted]
dagw 11y ago
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.