Open Stack

+1

From: Gabriel Hurley <Gabriel.Hurley at nebula.com<mailto:Gabriel.Hurley at nebula.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, November 27, 2012 11:35 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] Python and OS version support

I’d just like to throw it out there that it is possible to support Python 2.6.5 or later alongside Python 3… making the minimum bar 2.7 just makes it easier. The real problem is OpenStack’s massive number of dependencies which are in a horribly mixed state as far as support for various Python versions. I don’t think we can even begin to draw boundaries around certain versions for Python 3 support until we do a complete audit of all our dependencies.


-          Gabriel

From: Doug Hellmann [mailto:doug.hellmann at dreamhost.com]
Sent: Tuesday, November 27, 2012 10:15 AM
To: Daniel P. Berrange; OpenStack Development Mailing List
Subject: Re: [openstack-dev] Python and OS version support


On Tue, Nov 27, 2012 at 7:23 AM, Daniel P. Berrange <berrange at redhat.com<mailto:berrange at redhat.com>> wrote:
On Mon, Nov 26, 2012 at 08:40:15AM -0800, Monty Taylor wrote:
> Except where it comes to base python versions.
>
> If we take the above to be correct, it has the following effect:
>
> - We need to care about python 2.6 compatibility until such a time
> as there is a RHEL that has 2.7 in it.
> - 2.7 should be our current dev focus, so if possible we should code
> to 2.7 libs and then use backport packages like unittest2 to make
> 2.6 happy.
> - We can't REALLY start thinking about Python3 in earnest until a
> RHEL release comes out with python 2.7, because 2.7/3.3 are needed
> for source-code compatible code
>
> Net result - pretty much exactly what we're doing today, it just
> gets it down on paper a little better.
>
> Thoughts? Disagreements?
Even ignoring the question of what versions distros we're targetting
support, I think we should be conservative in both the base python
version, and external dependancies in general. I observe that there is
a general tendancy to move to the latest release of external depedencies
very quickly. As an example, Fedora 17 (which is not exactly an old
release - in fact it is the current up2date Fedora release still) is
already unable to satisfy OpenStack's min version requirements for
something as simple as pep8.

The view seems to be that things like DevStack / virtualenvs make it
easy to switch to newer versions, and so there's little-to-no downside.
This is mostly prioritizing easier coding for developers, over ease of
deployment & maintenence for both end users and distributors. Perhaps
this was the right approach early in OpenStacks lifetime, but with
people increasingly viewing OpenStack as production ready /  maturing
I think the current balance is wrong. Indeed I believe the overly eager
switch to new versions is actively harmful to the community as a whole.

I would like to see our guiding principal be to avoid min version upgrades
unless there is a significant (ie show stopper) problem with existing min
versions to is not practical to live with. If a new particular new feature
is really desired, then structure things so that the new feature is only
used if the corresponding version is available, and fallback to turning
off that feature otherwise. This avoids the need to upgrade min version
requirements, without preventing use of new features.

To your specific point of Python base versions, my view is that we should
aim for the lowest possible Python version. Yes, new python 2.7 version
introduces shiny new features over 2.6, but in reality it is entirely
practical to write OpenStack without requiring these new features. As for
Python 3.0, it may remove many warts from Python 2.x, but I really don't

It isn't about "shiny features," it's about support. Just as we don't have the resources to support old versions of OpenStack indefinitely, the Python development team has to declare EOL for older versions of Python.

Python 2.6 is currently only receiving security fixes. No other bug fixes or enhancements will be made. Even that level of support will stop in October of next year (http://www.python.org/download/releases/2.6.8/).

Python 2.7 is receiving bug fixes now, but will be cut off from support after another few years. The cutoff date isn't set, yet, but that's not an excuse to stick with old tools.

Failure to move will mean we won't be able to use fixes for existing libraries that drop support for 2.x or take advantage of new libraries without any support for Python 2. The progress from 2.x to 3.x in the rest of the Python community is slow, but steady. Many developers are already targeting 3.3 first, with 2.7 (or earlier) support an afterthought.

Doug

see much compelling reason to even consider supporting to that. Python
2.x is going to be around for a long time yet and I don't see any end
user relevant features of OpenStack that would be blocked by us sticking
with 2.x only and ignoring 3.x entirely. There is certainly plenty of
downside to increasing the min python above 2.6 for both os vendors and
end users.

Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121127/38fb3de6/attachment.html>