In article <m28w2uvgal....@web.de>, de...@web.de (Diez B. Roggisch) wrote: > Ned Deily <n...@acm.org> writes: > > In article <87zkvbytnk....@web.de>, de...@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, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
