Python in Linux - barrier to Python 3.x

[Ned Deily]

In article <m28w2uvgal.fsf at web.de>, deets at web.de (Diez B. Roggisch) 
wrote:
> Ned Deily <nad at acm.org> writes:
> > In article <87zkvbytnk.fsf at web.de>, deets at web.de (Diez B. Roggisch) 
> > wrote:
> >> The point is that the distro doesn't care about the python eco
> >> system. Which is what I care about, and a lot of people who want to ship
> >> software.
> > I don't think that is totally accurate or fair.  There is regular 
> > participation in the python-dev group by packagers from various distros.  
> > For example, Matthias Klose is not only the primary Debian Python 
> > maintainer, he is also has commit privileges for Python itself and he 
> > regularly contributes patches.  Currently, I see current Python 2.6.6 
> > and 3.1.2 packages in Debian testing with current Python 2.7 and Python 
> > 3.2 alpha coming along in Debian experimental.
> 
> I'm sorry, this was worded stronger than appropriate. Let me rephrase:
> The distros have their own (perfectly reasonable) agenda. Yet this may
> still conflict with the needs of users regarding e.g. contemporary
> package availability. I already mentioned in another post that the
> current debian stable features TurboGears 1.0.4. Which is by itself a
> problem, but also ties a lot of dependencies to "ancient" versions. So
> frankly, if I want to run (which in fact I do) a perfecly fine
> TurboGears2 system on lenny, I'm *forced* to use virtualenv and
> consorts.
> 
> In other words: I think that the goals of a linux distribution don't
> necessarily are the same than those of a python package maintainer. In
> an ideal world, they would be congruent. But they aren't. My wish would
> be that unless that this congruency is achieved (which isn't feasible I 
> fear), a
> python-only package management solution can be implemented and be
> adopted even by the distros without neglecting their own issues. 

Thanks for the clarification.

While I too wish such a general python-only package management solution 
existed, the big blocker is and will remain the effort required to 
manage the package quirks (local patches), package dependencies, 
platform differences, unit testing, unit testing across multiple 
platforms, system testing (packages with their dependencies - think 
Django or Zope), packaging and distribution.  In short think of all the 
steps and infrastructure that go into, say, the Debian development 
process, which - not to slight the others out there - I consider to be 
the most mature and rigorous of the large open source integration 
projects.  While much of it can be (and, to some extent, already is) 
automated, there is still a strong human involvement required at nearly 
all stages.   Repeatable and predictable does not necessarily mean 
totally automated or scalable.  Getting to where Debian is today has 
required an almost superhuman and ongoing effort and dedication over 
many years by many people.  Having been intimately involved over the 
years in various software release processes most involving hundreds of 
people, I remain somewhat awestruck in what they have accomplished.  I'm 
not optimistic that the resources or leadership are available in the 
community to make something similar happen for Python packages.  It's an 
enormous task.

-- 
 Ned Deily,
 nad at acm.org