Re: Python versions for Ubuntu 10.10 (Maverick Meerkat)
[Barry Warsaw, 2010-05-22]
> On May 19, 2010, at 11:00 AM, Piotr Ożarowski wrote:
>
> >[Barry Warsaw, 2010-05-18]
> >> We can also recognize that Ubuntu and Debian may ultimately
> >> make different decisions, but they should be one of timing rather than
> >> substance. What I mean by that is that we can use the basic fact of our
> >> different release schedules to our advantage.
> >
> >sure, as long as Debian is not affected (and Ubuntu doesn't waste too
> >much of our work)
>
> So, how can we make sure that doesn't happen? IOW, how can I begin to
> experiment with a Python 2.7 transition in a way that will benefit Debian as
> well?'
Simply avoid doing transitions with significant changes in either upstream
code¹ or in interpreter packaging² as otherwise the transition will be
made by few overloaded developers who have to update lots of packages really
urgently (just few days ago I noticed yet another "fix" made by Python
core developer this time) or by people who don't use³ Python at all.
[¹] f.e. changes in API, absolute imports in 2.7 would be one of those,
right now I don't see such changes in 2.7, but I didn't play much
with it yet
[²] f.e. --prefix or dist- vs. site-packages change
[³] without seeing the bigger picture (i.e. not being a long term
maintainer for given package), it's really easy to make a mistake,
even if a package builds fine on all architectures, passes all tests
(with 100% test coverage), is lintian and piuparts clean, module imports
fine, works fine... you still can end with bugs like LP:418280 (and I
can easily imagine breaking lots of other packages by such bugs).
Note that I assume Ubuntu maintainer *did* check all these things
before uploading.
> >> With Ubuntu's time-based and
> >> LTS releases, we can often be more aggressive in our decisions,
> >
> >we have experimental for aggressive changes...
>
> experimental is overlayed on top of unstable, right?
right
> experimental's got
> Python 2.6.5 right now, but once that lands in squeeze does it make sense to
> get Python 2.7 into experimental?
testing, unstable and experimental have Python 2.6.5 right now, the only
difference is experimental has 2.6 set as default since few days. 2.7 is
in experimental as well, it's not marked as supported, though. Adding
2.7 to the list of supported Python versions will make it a lot easier
to build packages with 2.7 support (f.e. in experimental enabled
pbuilder) and test it in unstable (with 2.7 installed from experimental)
> >> https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview/Python
> >
> >* how many Ubuntu developers at least read PEP 3147?
>
> Probably only a handful.
sorry, but I don't think it's enough to do the python3.2 transition in
few months (please note that we (I?) were told that that f.e. pyshared
related changes in python-central were tested really well by Ubuntu
developers)
> I'd guess that only a handful of upstream Python
> core devs have read it too though. ;)
I think most upstream Python core devs do not try to use two (or more)
different Python versions with hundreds of 3rd party (sometimes really
old) modules and applications, so they probably do not care much about
issues that PEP3147 tries to solve.
> OTOH, I think most Python developers,
> and Python packages, will not be affected by PEP 3147 since most don't care
> about where their pyc files live.
Python developers (including 3rd party module authors) - sure (if they
have to care about it, it's a bug in Python itself, IMHO)
Python packages - I don't agree with you here.
Before I will ask you my next question (and point to issues with
dist-packages change), please let me know how do you want to share .py
files between two different Python versions (including exceptions where
.py file cannot be shared, f.e. due to __future__ imports).
> Some will of course and we will have to fix
> them or ask their authors to fix them. Still, I suspect that the intersection
> of packages that care *and* are ported to Python 3 is probably ridiculously
> small right now. ;) That would change of course if we backport to Python 2.
If Ubuntu will introduce something that Debian will never support or
will choose to do it differently, there will be problems sooner or
later. The fact that you will start with small number of packages
doesn't really matter.
> >* how many of them will work on huge changes that packages need in order
> > to work with PEP3147?
>
> I don't know. What exactly needs to change?
f.e. helper tools are not ready for it; we didn't agree how to share .py
files on hard disk yet; some packages started adding 3.x support in the
binary package which provides 2.X module (and it looks like python3
maintainer wants to separate them)... is that enough for a start? (I'm
afraid the list will be much longer)
> Not the packages themselves, but
> the packaging? How much of that can be automated?
I cannot tell you what can be automated if I don't know which path will
be chosen (I'm still waiting for Matthias' proposals and discussion on
this mailing list)
> >* will Ubuntu force Debian to use these changes (you will *have to*
> > introduce them in 10.10 if you want to use python3.2 on desktop)?
>
> I hope not *force*. I hope we can do a lot of the work and make it available
> to Debian.
By "forcing" I mean introducing changes in Ubuntu and uploading to
Debian later, without our influence on design decisions or possibility
to change something and with months of delays between Ubuntu and Debian
uploads (see f.e. python-central NMU saga and reasons why I finally
decided to switch to python-support)
> >FYI: I've been there, I tried to fix 2.6 related bugs in Ubuntu without
> >possibility to test them on Debian, it's not fun at all and I will not
> >do it again (since I got not nice comments and delays in return)
>
> Well, if we understand now the types of problems that can come up, then
> hopefully we can coordinate fixes for them in a much more positive way. I
> still don't have a good understanding of what - outside of Python 2.7
> compatibility itself - needs to change.
Python 2.6.4 -> 2.6.5 upgrade broke one of my packages in Ubuntu, I
suspect the diff between Python 2.6.5 and 2.7 is a little bit bigger
and thus there are more potential problems. I don't care about which 2.x
version Maverick will ship anymore (I already left #ubuntu-motu). I just
hope it will not introduce packaging changes that will break "my"
packages or "my" packages will not be changed by people who don't use
them.
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Reply to: