Django 1.6's lifespan for security updates?

[Christian Hammond]

Hi,

According to https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions, it appears that when Django 1.8 is released, Django 1.6 will no longer receive security updates. I wanted to verify that this is true, and ask whether there's a possibility of an extension on this timeframe.

I'll explain the situation we're in.

I manage Review Board, a code review tool currently in use by several thousand companies/organizations, many of whom (according to stats we have available) are on Python 2.6. From conversations we've had, many of these companies are on LTS releases of Linux distributions that bundle Python 2.6 by default (including their mod_wsgi support, etc.), and are likely to remain on it for the next year or two. Not to mention Amazon Linux and other variants are all sticking with 2.6 for now as well.

This puts us in a difficult position where we are unable to drop Python 2.6 support without affecting a large number of installs out there (12% of our base, or over 700 installs), meaning we haven't yet been able to make the transition to Django 1.7/1.8 (as much as we want it). (It also makes the lives of packagers easier who are trying to support software stuck in this situation, from what I'm being told, as they're responsible for security updates.)

As Django 1.6 is the last release to support Python 2.6, it would be very nice to have a longer-term security release plan while companies transition over. We see this happening, but slowly.

Is there any possibility of treating Django 1.6 as a special LTS release?

Thanks for considering :)

Christian

--

Christian Hammond

Review Board - https://www.reviewboard.org

Beanbag, Inc. - https://www.beanbaginc.com

[Carl Meyer]

Hi Christian,

On 03/10/2015 01:44 PM, Christian Hammond wrote:
> According to
> https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions,
> it appears that when Django 1.8 is released, Django 1.6 will no longer
> receive security updates. I wanted to verify that this is true, and ask
> whether there's a possibility of an extension on this timeframe.

It is true, and I don't think it should be extended.

> I'll explain the situation we're in.
>
> I manage Review Board, a code review tool currently in use by several
> thousand companies/organizations, many of whom (according to stats we
> have available) are on Python 2.6. From conversations we've had, many of
> these companies are on LTS releases of Linux distributions that bundle
> Python 2.6 by default (including their mod_wsgi support, etc.), and are
> likely to remain on it for the next year or two. Not to mention Amazon
> Linux and other variants are all sticking with 2.6 for now as well.
>
> This puts us in a difficult position where we are unable to drop Python
> 2.6 support without affecting a large number of installs out there (12%
> of our base, or over 700 installs), meaning we haven't yet been able to
> make the transition to Django 1.7/1.8 (as much as we want it). (It also
> makes the lives of packagers easier who are trying to support software
> stuck in this situation, from what I'm being told, as they're
> responsible for security updates.)
>
> As Django 1.6 is the last release to support Python 2.6, it would be
> very nice to have a longer-term security release plan while companies
> transition over. We see this happening, but slowly.
>
> Is there any possibility of treating Django 1.6 as a special LTS release?

I sympathize with your situation, but Python 2.6 reached end-of-life on
October 29, 2013 (a year and a half ago now), and since then has been
unsupported and not receiving security updates. I don't think the Django
core team should set a precedent of extended support for Python versions
which are themselves unsupported by the core Python developers.

If some Linux distributions are backporting Python security patches to
2.6 themselves in order to extend its lifetime in their distribution,
perhaps it would make sense to ask them whether they will also backport
Django security patches to Django 1.6. (I would guess that some of them
may already be planning to do so, and may even have already done so for
previous Django releases in the past.)

Carl

[Avraham Serour]

each django deployed on the machines with python 2.6 should already be on the project virtualenv

I suggest to compile python 2.7 yourself and create  the virtualenvs based on the compiled python, no need to replace it system-wide

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54FF6991.7080909%40oddbird.net.

For more options, visit https://groups.google.com/d/optout.

[Stephen Gallagher]

On Tuesday, March 10, 2015 at 6:01:28 PM UTC-4, Carl Meyer wrote:

I sympathize with your situation, but Python 2.6 reached end-of-life on
October 29, 2013 (a year and a half ago now), and since then has been
unsupported and not receiving security updates. I don't think the Django
core team should set a precedent of extended support for Python versions
which are themselves unsupported by the core Python developers.

If some Linux distributions are backporting Python security patches to
2.6 themselves in order to extend its lifetime in their distribution,
perhaps it would make sense to ask them whether they will also backport
Django security patches to Django 1.6. (I would guess that some of them
may already be planning to do so, and may even have already done so for
previous Django releases in the past.)

So, here's the basic problem. The distributions that are packaging python 2.6 are, basically Red Hat Enterprise Linux 6 and its clones (CentOS, Scientific Linux, Oracle, etc.) and SUSE Linux Enterprise Server 11. These two distributions make up a significant percentage of the enterprise deployment space. Neither of these distributions ships Django itself. For RHEL, the Fedora Project provides the EPEL add-on repository which is unsupported and *may* carry Django (though it has proven to be difficult, more on that in a minute). For SLES, there is OpenSUSE which acts similarly. These are community-sponsored and generally limited to only packaging what upstream provides, since with no corporate backing and engineering support, backporting patches from newer releases is unlikely to happen.

The reason that neither of these distributions carries Django is specifically because of the short lifecycle of Django. The LTM releases (1.4 and the upcoming 1.8) are somewhat better aligned with the goals of enterprise distributions, but even those approximately three-year lifespans are significantly shorter than the ten years that the enterprise distributions want to maintain. So the chances of Django ever being shipped by a company capable of supporting it for that length of time is basically zero. (Not unless Django someday becomes a critical part of the standard Linux platform).

In the Enterprise software space, there's an average of a two-year period between a new version of software becoming available and companies actually deploying it. This essentially means that an LTM release needs to be at minimum four years long, since it will require half of the supported lifecycle for consumers to convert over to it and they'll need the other half of it in order to migrate to the next version. (Also, most companies don't like constant migrations like this).

So, I realize that Django 1.6 is not an LTM release, and so asking for an extension on it is probably unlikely to happen. I'd like to see 1.4 supported for at least the two-year migration period to 1.8, though (with 1.8 planned to accommodate the future migration as well).

Also, is there any chance at all that python 2.6 support could be reintroduced to Django 1.8? That would make it plausible to migrate existing users to an LTM release at least, buying time to figure further plans out.

[Andreas Kuhne]

--

You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

I think the main thing here is that python 2.6 has already reached end of life in October 2013. That's 1 ½ years ago! So opting for a dead version of python to be used is not really the right way to go for the django developers IMHO. I understand that python 2.6 is available via the package manager in all of the enterprise distributions you are citing, however, it should be possible (as someone already suggested) to compile at least 2.7 if not python 3 yourself and run them in virtualenvs (which you should be doing anyway). 

Maintaining old versions of python and several versions of the django framework will only make things harder for the developers, which will eventually just delay the development process, making vital security releases take longer to be deployed. I understand the problems you are having with python 2.6 not being supported, but frankly I don't see that to be a django issue, but rather the enterprise server versions that are running a python version past it's end of life. 

Regards,

Andréas

[Bill Freeman]

You should really decouple yourself from the distro's choices, saving headaches in the future.  Let me expand on Avraham's suggestion.

There is little difficulty in having more than one version of python on a box.  The main caution here is that the distrio's use of python might depend on that python being a 2.6.  That means that (ignoring PATH modifications and use of virtualenvs) that typing "python" should get you a 2.6..  If your distro offers a 2.7 package, it is probably built so that "python" gets you a 2.6, and "python2.7" gets you a 2.7, and the distor's python based tools will continue to work (as) fine (as they ever did).

But I don't recommend using a distro 2.7 package, even if available.  You become subject to them doing something bizarre in an update.  You have much better control if you build it yourself.  Avoiding replacing what you get when you type "python" is easy enough:  instead of "make install" use "make altinstall", which does everything except "ln python2.7 python".  Another approach, used where I work, is to set the install path to a directory not included in the default PATH setting, but then you can't simply type "python2.7" (at least as root) to get a 2.7, or, more to the point, you have to give a full path to virtualenv's -p flag.  It takes some fiddling (last time I did this) to be certain that you have all the necessary development libraries (-devel on RPM based systems), since, for some, python will still build, but some features won't be available.  You may not care about some of them now (readline support is a case in point) but they don't hurt anything, and it's better than rebuilding later.  Document what you had to add for future reference.

Another requirement, if you are using mod_wsgi, is to re-link it against your python.  A given httpd - mod_wsgi install can only use one version.of python.  This, in practice, means building your own mod_wsgi, rather than using a distro version.  And if you're going this far, you may as well take full control by building Apache httpd as well, though, so long as a suitable development package is available, you may not need to..  It's not as big a deal as it may sound.

If you're not using httpd/mod_wsgi, I can't offer any advice on what may be required, since I haven't done my own installs of ngnx, etc.

Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALXYUbmpPr6sDqQDQZ0iAUjK%3DJTmqo5mUL1jyDmGa2hFD_U1%3DQ%40mail.gmail.com.

[Tom Evans]

On Wed, Mar 11, 2015 at 12:53 PM, Andreas Kuhne
<andrea...@suitopia.com> wrote:
> I think the main thing here is that python 2.6 has already reached end of
> life in October 2013. That's 1 ½ years ago! So opting for a dead version of
> python to be used is not really the right way to go for the django
> developers IMHO. I understand that python 2.6 is available via the package
> manager in all of the enterprise distributions you are citing, however, it
> should be possible (as someone already suggested) to compile at least 2.7 if
> not python 3 yourself and run them in virtualenvs (which you should be doing
> anyway).

For enterprise operating systems, the packages that are provided by
them, are supported by them. Python 2.6 is still the supported python
version in RHEL 6 - its not end of life - and will continue to be
supported until (at the earliest) Oct 31, 2016. Up until that point,
any security issue in python 2.6 will be backported by the OS vendor,
and a new package is released.

For instance, in RHEL 6, the supported version of apache is 2.2.15.
2.2.15 is old, it was released March 2010, and has lots of bugs, but
when you install it in RHEL 6, you actually get (today) 2.2.15.39.el6,
which is patched to fix all security issues between 2.2.15 and 2.2.29
(and possibly bug fixes for things that have yet to be released by
httpd project).

Using a self compiled python 2.7 would not be supported by the OS
vendor, and so would require a separate support contract. For RHEL6,
you can "get" python2.7 by using the Fedora SCL collections, but this
also isn't covered by the OS support contract (iirc).

This is not hypothetical issues. If you build your own python package,
you are responsible for building, packaging and supporting it. When
there are security issues with the version you have, you need to know
about it, and have enough time to deal with it. If your business is
not packaging up software, that is a waste of time, it is better to
pay someone to do it for you, which is why we have vendor supported OS
+ packages, you simply need to have the support contract.

Obviously, not everyone has these issues. Not everyone cares - move
fast and break things is good..

Cheers

Tom

[Carl Meyer]

Hi Stephen,

It certainly sounds like there's an opportunity here for someone to
provide extra-extended security-backport support for certain Django
releases (beyond the ~3.5 years we'll typically support an LTS release
under current policy), to accommodate these enterprise users on dead (to
upstream) Python versions.

I remain quite unconvinced that this "someone" should be the Django core
team. I think the core team's limited energies are better spent
continuing to move Django forward.

> So, I realize that Django 1.6 is not an LTM release, and so asking for
> an extension on it is probably unlikely to happen. I'd like to see 1.4
> supported for at least the two-year migration period to 1.8, though
> (with 1.8 planned to accommodate the future migration as well).

I think the current plan is for a 6-month support window for 1.4 after
the release of 1.8. (Tim can probably correct me if I'm wrong - I know
there was discussion about 3 months vs 6 months; I thought we settled on
six.)

> Also, is there any chance at all that python 2.6 support could be
> reintroduced to Django 1.8? That would make it plausible to migrate
> existing users to an LTM release at least, buying time to figure further
> plans out.

I think that's extremely unlikely.

Carl

[Stephen Gallagher]

On Wednesday, March 11, 2015 at 12:00:25 PM UTC-4, Carl Meyer wrote:

It certainly sounds like there's an opportunity here for someone to
provide extra-extended security-backport support for certain Django
releases (beyond the ~3.5 years we'll typically support an LTS release
under current policy), to accommodate these enterprise users on dead (to
upstream) Python versions.

I remain quite unconvinced that this "someone" should be the Django core
team. I think the core team's limited energies are better spent
continuing to move Django forward.

Sure, I both understand and respect that. The problem is that it moves the problem further up the stack and closer to the end-users.

The platform vendor (Red Hat, SUSE, etc.) won't take on the responsibility for every package, or likely any package that doesn't directly support something they are trying to sell to a customer. Hence why the major vendors don't ship a copy for themselves.

The community-supported add-ons are all volunteer efforts, most often by amateur packagers who are only in rare occasions equipped to do real engineering work to backport patches. These people rely on the upstreams continuing to support the packages so they can package the updated releases. Sometimes this leads to an upstream killing off support for a release and the add-on repository being unable to upgrade. This is bad for everyone, because over time this *will* (not may) end up with packages in the wild with known vulnerabilities and little-to-no way to address it.

So the responsibility then goes to the framework developers who have more engineering knowledge about the subject but generally fewer resources to spare. So the answer there is that "someone else" needs to step up and take over the security maintenance. Unfortunately, that now brings it up to the application developers.

Application developers rarely know the internals of the packages they depend on; generally they consume the public API and don't think twice about the rest of the implementation. Similar to the framework developers, they have limited resources best spent on delivering something their customers can use. With a lack of knowledge of the framework, they're not generally equipped to do the maintenance themselves. Traditionally, this results in a functional equivalent to the worst-case of the add-on repository situation above: application developers just bundle a version of the framework that worked when they implemented it and *never update it*. This inevitably ends with something that appears to work for their users but will eventually bit-rot and become a liability.

Lastly, we have the application users. Let's be honest: do we want end-users responsible for maintaining the complete stack? They're going to do what they always do: find and install one version (no matter how old) and just use it until something goes wrong, at which point they have no one to call who knows the system and can fix it for them.

When looking at the big picture, the best thing for end-users is for the lowest levels of this stack to take control of maintenance for it. In cases where the stack is critical infrastructure (like the Python interpreter itself), the OS vendor will take it over, even to the degree of maintaining it past its upstream end-of-life. Where it's not critical infrastructure, the upstream developers are the best-equipped to manage maintenance. Further up in the stack than that, you have a very unbalanced scale of decreasing knowledge vs increasing need for stability.

[Tim Graham]

Having managed the last few security releases for Django, I'll say it's one of my least favorite tasks and I'm quite looking forward to dropping support for 1.4 (which supports Python 2.5) and 1.6 (Python 2.6). But, if there's sufficient interest that we could raise funds to support this effort outside of my normal duties as Django fellow, there's a chance you could convince me to continue backporting patches and preparing releases for these versions. I'm not quite sure how the logistics of such an arrangement would work, but just thought I'd throw the idea out there and see if anyone is ready to back the effort financially. I'd want the endorsement of the core team before finalizing anything.

[Christian Hammond]

Hey Tim,

I can definitely relate. It's not fun maintaining security releases (or fixes of any sort) for older versions of the software. Been there (am there now).

We're trying to encourage people to move to Python 2.7 so that we can upgrade, but this is the enterprise. It's not an easy task. (Look how long Microsoft tried to get people off of IE6.) Python 2.6 is still wildly populate in the enterprise. The sad fact is, even once we leave Python 2.6 behind, there's going to be at least a few hundred companies with servers running Django 1.6.x who will not be upgrading for quite some time, no matter what any of us do or say (just as there are still at least a hundred running against Django 1.4). Once security releases stop for 1.6, these companies are going to be vulnerable to any new exploits.

I wholeheartedly agree about using virtualenv and staying on top of the latest releases, but we've had little luck in getting administrators to move in that direction. We've been trying to work with a handful recently who insist on running older versions with very custom deployments because "it works and we don't want to risk anything," but at the same time they're quick to pull in any security updates offered by RHEL/us/whoever, as it's a liability otherwise. Especially since, as others have said, they have support contracts in place that they're paying a lot of money for, and will not violate. The advice on virtualenvs and building your own Python is good, and I appreciate it and agree with it, but it just won't make a dent in the number of enterprise Python 2.6/Django 1.6 users out there.

So... we're in a tough position now. Hundreds of companies *will* be on Django 1.6 for the next couple of years at least, no matter what advice we give or what any of us choose to do. Since newer versions of Django don't support Python 2.6, it'll be even harder for these companies to upgrade without rebuilding their infrastructure, further ensuring that they'll stick with what they have.

I wish I could say that we could fully-fund future Django 1.6 security updates, but our company is young and still trying to stay afloat, so our funds are limited. I'll personally contribute what I can afford to the cause, if I knew what sort of target there was, and how likely this would be to happen. I don't want to leave our users hanging and vulnerable.

The only other course of action I can think of is to maintain some sort of unofficial fork of Django 1.6 with backported security updates, but I think that's just going to cause more problems than it solves in far too many areas.

Maybe I'm rambling at this point. It's a pretty major issue for us, and we're feeling a bit stuck on what to do about this. Since we use Django as a component in a distributable webapp, instead of in-house in a controlled environment, we seem to hit problems that most people don't have to deal with.

Thanks again for your thoughts on this, everyone.

Christian

[James Bennett]

On Wed, Mar 11, 2015 at 3:54 PM, Tim Graham <timog...@gmail.com> wrote:

Having managed the last few security releases for Django, I'll say it's one of my least favorite tasks and I'm quite looking forward to dropping support for 1.4 (which supports Python 2.5) and 1.6 (Python 2.6). But, if there's sufficient interest that we could raise funds to support this effort outside of my normal duties as Django fellow, there's a chance you could convince me to continue backporting patches and preparing releases for these versions. I'm not quite sure how the logistics of such an arrangement would work, but just thought I'd throw the idea out there and see if anyone is ready to back the effort financially. I'd want the endorsement of the core team before finalizing anything.

Way, way, *way* back in the day, there was unofficial bugfix support for pre-magic-removal versions of Django run on the basis of "some people who need it step up and do all the work". It was solely done in SVN and never involved issuing new releases, so anyone running off the maintenance branch had to just update their checkout whenever a fix landed in it.

I'm not opposed to allowing that again -- and in fact I was one of the people who did extended maintenance for pre-m-r Django because my employer at the time needed it -- but I think we should carefully consider how it's going to work before trying it, since we no longer have the ability to give partial commit bits.

[Mike Dewhirst]

Maybe ... some effort to solve the infrastructure issue would make it
worth kickstarter funding.

A couple of colleagues are pushing me towards Docker as a packaged
Python 3.4 environment but that is beyond my interest atm.

I am running a dedicated production server on Ubuntu 14.04 which more or
less forces me to stick with Python 2.7. I would like to move to Python
3.x using virtualenv but I don't want to mess with stuff which is working.

Maybe a really nice solution would be a kickstarter project to develop a
deployment tool to create a predictable, supportable modern environment
on "old" boxes and to vaccuum up the existing Django sites running on
bare metal.

In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv
approach would be covered by standard Ubuntu support. I have only
glanced at Docker so I don't know how valid that might be.

Just a random thought.

Mike

> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com

> <mailto:django-users...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto:django...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-users/aa815ee5-b0d0-47b2-bdd6-824c9209f356%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/aa815ee5-b0d0-47b2-bdd6-824c9209f356%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Russell Keith-Magee]

Agreed that this is an approach we could take - but I don't think the lack of a partial commit bit isn't a major issue IMHO.

At a technical level, Git gives anyone the ability to fork Django's repository. There's no *technical* reason that someone couldn't maintain a 1.6 branch *right now* - the only restrictions are that they couldn't call that repository official (as per BSD licensing terms), and they wouldn't have access to security patches until everyone else did.

However, both of these are solvable problems. 

The only thing that makes Django's Github repository "official" is because the core team says it is. If someone wants to take on the task of back porting all the security patches to 1.6, we (as a project) can point to that repository if we want. If we're interested in doing 1.6 support as an "unofficial" subproject, then it seems appropriate to me that the repository *isn't* Django's core repository; picking a third-party vendor's repo sounds like the right way to do it. 

As for getting the patches ahead of time - I'd be more than happy for an appropriately qualified and trustworthy individual/company to be added to the security pre-notification list.

So - it really just comes down to someone having the enthusiasm to maintain the branch. Christian has been around the Django project for a long time (he was a contributor to Django Evolution from very early on, and took over maintenance of the project when I moved on). If he's got a commercial interest in continued 1.6 support, and he can spare a couple of hours to do a backport when a security issue is announced, I'd have no problem adding him to the pre-notification list, and adding some documentation pointing at his fork of Django as an "unofficial 1.6 repository". If Christian hasn't got the time to do this, but he (and/or anyone else) can throw some funds at Tim, Tim is already on the security notification list.

Yours

Russ Magee %-)

[Russell Keith-Magee]

On Thu, Mar 19, 2015 at 2:27 PM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:

Maybe ... some effort to solve the infrastructure issue would make it worth kickstarter funding.

A couple of colleagues are pushing me towards Docker as a packaged Python 3.4 environment but that is beyond my interest atm.

I am running a dedicated production server on Ubuntu 14.04 which more or less forces me to stick with Python 2.7. I would like to move to Python 3.x using virtualenv but I don't want to mess with stuff which is working.

Maybe a really nice solution would be a kickstarter project to develop a deployment tool to create a predictable, supportable modern environment on "old" boxes and to vaccuum up the existing Django sites running on bare metal.

In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv approach would be covered by standard Ubuntu support. I have only glanced at Docker so I don't know how valid that might be.

Docker isn't needed for any of this, especially on Ubuntu 14.04. Python 2 and Python 3 can co-exist, and Python3.4 is part of the standard repo for Ubuntu 14.04. Even if it wasn't, you could install Python to a user-space directory, and create a virtualenv based on *that* version of Python.

However, in a broader sense, I think you'll find that the audience of people who need this tool are almost by definition the set of people who wouldn't be able to use it.

If a company is locked into Python 2.6, it's because they're on a Enterprise Supported Version (tm) of some operating system; in that sort of environment, installing and using *anything* that isn't provided by the vendor is a non-starter. Even if a tool *was* developed, you'd need to get it deployed in-channel - and that could take years... or you could just upgrade your system :-)

FWIW: This is the exact type of problem that RedHat software collections are designed to fix - RHEL wore a lot of flack for being so pathologically behind the times (the Python interpreter being one key component). RedHat's response has been to introduce software collections - an officially mandated set of tools that can be updated much more regularly, official blessed by the manufacturer.

https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/

 

Obviously, this won't help if you're not on RHEL6 or 7 - but it's an indication that some enterprise vendors are listening.

Yours,

Russ Magee %-)

[Stephen Gallagher]

On Mar 19, 2015, at 3:18 AM, Russell Keith-Magee <rus...@keith-magee.com> wrote:

On Thu, Mar 19, 2015 at 2:27 PM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:

Maybe ... some effort to solve the infrastructure issue would make it worth kickstarter funding.

A couple of colleagues are pushing me towards Docker as a packaged Python 3.4 environment but that is beyond my interest atm.

I am running a dedicated production server on Ubuntu 14.04 which more or less forces me to stick with Python 2.7. I would like to move to Python 3.x using virtualenv but I don't want to mess with stuff which is working.

Maybe a really nice solution would be a kickstarter project to develop a deployment tool to create a predictable, supportable modern environment on "old" boxes and to vaccuum up the existing Django sites running on bare metal.

In my case, Ubuntu does support Python 3.4 (I think) so the virtualenv approach would be covered by standard Ubuntu support. I have only glanced at Docker so I don't know how valid that might be.

Docker isn't needed for any of this, especially on Ubuntu 14.04. Python 2 and Python 3 can co-exist, and Python3.4 is part of the standard repo for Ubuntu 14.04. Even if it wasn't, you could install Python to a user-space directory, and create a virtualenv based on *that* version of Python.

However, in a broader sense, I think you'll find that the audience of people who need this tool are almost by definition the set of people who wouldn't be able to use it.

If a company is locked into Python 2.6, it's because they're on a Enterprise Supported Version (tm) of some operating system; in that sort of environment, installing and using *anything* that isn't provided by the vendor is a non-starter. Even if a tool *was* developed, you'd need to get it deployed in-channel - and that could take years... or you could just upgrade your system :-)

I think you'll find that this is a bit overstated. Customers install plenty of software that isn't provided by Red Hat. I think you might be amazed at how popular the public Extra Packages for Enterprise Linux repository is (it's a sub-project of Fedora that provides many packages from the Fedora collection built for RHEL).

What they don't do (except in dire need) is install alternative versions of software that *is* provided by their support contract. This is because for most companies, the added features aren't worth the self-maintenance. No one who isn't an OS vendor can keep up with the security issues on all of that software.

FWIW: This is the exact type of problem that RedHat software collections are designed to fix - RHEL wore a lot of flack for being so pathologically behind the times (the Python interpreter being one key component). RedHat's response has been to introduce software collections - an officially mandated set of tools that can be updated much more regularly, official blessed by the manufacturer.

https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/

 

Obviously, this won't help if you're not on RHEL6 or 7 - but it's an indication that some enterprise vendors are listening.

Yes and no, but it's not much of an answer because the double-edged sword here is that the Software Collections also have a much shorter supported lifespan than the main operating system (which guarantees a stable platform for at least ten years). For most companies, rebuilding "that one internal app we maintain" every three years is unrealistic. Not everyone is Twitter or Netflix, doing multiple deploys an hour.

Speaking anecdotally, the average lifetime I've seen of customer-produced internal apps is usually about 7-8 years (generally equivalent to whenever they moved to the latest RHEL release until the moment it goes out of support... sometimes past that, unwisely). You do not want to know how many datacenters are still running RHEL 4 and even RHEL 3.

Yours,

Russ Magee %-)

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/B74QJaqA0b4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.

Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq848g%2BUavE0giY2cogrh%3DwY2OzxbeHX9Bv0_SXFD0v0L0oQ%40mail.gmail.com.

[Carl Meyer]

I agree with all of this. I think that the Django core team will not
provide this extended support for 1.6 (because it gives the impression
that Python 2.6 is a supported and secure platform, which is only true
for the subset of our user base on certain extended-support distros),
and I don't think that extended-support releases of 1.6 should or will
ever appear on pypi.python.org/pypi/Django.

But I think that anyone who feels the need for this extended support can
feel free to raise the resources to make it happen and do it in a github
fork. If someone planning to maintain such a fork applied for
pre-notification of security releases, and could demonstrate significant
support for their effort, I would be in favor of that application.

And I think that if "that person" ends up being Tim Graham, as an
individual outside of his duties as Django Fellow, that's his choice and
I don't see any problem with it. We've already established a precedent,
several times over, for members of the core team to be paid for certain
tasks that parts of the community need or want that aren't getting done
otherwise. I would not support the DSF or Django core team sponsoring
the fundraising for this effort, but if a part of the community raises
the funds and Tim wants to accept said funds and do the work, more power
to him, as long as it doesn't detract from his other work as Django Fellow.

Carl

[Tim Graham]

Discussion to be continued on django-developers: https://groups.google.com/d/topic/django-developers/69fOquu8v-U/discussion