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 On Wed, Mar 11, 2015 at 8:53 AM, Andreas Kuhne <andreas.ku...@suitopia.com> wrote: > > 2015-03-11 13:28 GMT+01:00 Stephen Gallagher <step...@gallagherhome.com>: > >> >> 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. >> >> -- >> 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+unsubscr...@googlegroups.com. >> To post to this group, send email to django-users@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 >> <https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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 > > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@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/CALXYUbmpPr6sDqQDQZ0iAUjK%3DJTmqo5mUL1jyDmGa2hFD_U1%3DQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CALXYUbmpPr6sDqQDQZ0iAUjK%3DJTmqo5mUL1jyDmGa2hFD_U1%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@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/CAB%2BAj0tuT-LKMiKgHHCPM6CuhURFawsoXw30bNhERVaNJvnn%3Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
