On 21 March 2015 at 22:19, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, 21 Mar 2015 21:52:34 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 19 March 2015 at 07:51, Donald Stufft <donald@stufft.io> wrote:
I’ve long wished that the OS had it’s own virtual environment. A lot of problems seems to come from trying to cram the things the OS wants with the things that the user wants into the same namespace.
I'm more wanting to go in the other direction and suggest to folks that if they're not *scripting the OS*, then the system Python isn't what they want, and they should be using at least a virtual environment,
So that defeats the whole point of having a system distribution.
Given how many of the operating system packages are written in Python, it really doesn't - system administrators getting to use Python to script the OS is a secondary purpose, the system Python installation is mostly there to make the OS itself work (if it wasn't for that, migrating the system Python to Python 3 would have been a lot simpler!). In my view, running system independent applications in the system Python is at best a tertiary purpose - many of those apps (especially web services) *don't want* to be using system modules at all, which is why virtualenv switched to disabling the global site-packages by default.
I don't have any stakes in Debian / RedHat etc., but that sounds a little bit ridiculous to me ;-) On the other hand, perhaps it would allow ditching any requests to keep code compatible with old versions such as 2.6.
That's exactly the reason for the preference - unless they're specifically wanting to script RHEL/CentOS 6 or a similar long term support version at this point, ideally folks should be able to use Python 2.7 as their baseline version by now. RHEL/CentOS 7 are both on 2.7, while Python 2.7 has been available for RHEL/CentOS 6 by way of software collections for a couple of years now. When Python 2 goes EOL upstream in 2020, the standard 10 years of support on RHEL 7 will still have 4 years left to run - I'd prefer to see most folks migrated to a Python 3 software collection by then (or failing that, at least to the Python 3 stack Slavek is aiming to get into EPEL 7). Unfortunately, as far as I am aware, Debian Stable and Ubuntu LTS don't yet have a distro-endorsed equivalent of softwarecollections.org, and it's not yet clear if running on a faster moving base distro in a Docker or Rocket container will be an adequate alternative. I believe SCLs moved over to using Linux environment modules as the backend tech in 2.0 (for compatibility with existing HPC environments), so it should likely be possible to adapt them to work with APT in addition to RPM, but that requires finding folks both interested in doing the technical work, as well as in making the case for SCLs as a feature in the relevant distros (they're a large enough departure from the traditional mode of operation of a Linux distro that it took a long time to find a stable upstream home for the ongoing maintenance of SCLs for the Fedora/RHEL/CentOS ecosystem - primary maintenance responsibility finally landed earlier this year as a CentOS SIG) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia