> Yes, I am assuming that existing projects would at some point introduce a 3.x > version and maybe continue a 2.x version as separate distros, similar to > Python itself. Then the large number of existing unqualified dependencies > on, > say SQLObject, would pull in the higher 3.x version and crash. It's the > older > projects that don't get updated often that are at risk of being destabilized > by the arrival of 3.x specific code in PyPI. Are developers for Python 3.x > encouraged in 3.x guidelines to release 'fat' distributions that combine 2.x > and 3.x usable versions?
Passive voice is misleading here: encouraged by whom? *I* encourage people to consider that option, rather than assuming it couldn't possibly work. Whether it actually works, I don't know. I hope it would work, and I hope it would not be fat at all. > Perhaps a convention of a keyword or more likely a new trove classifier that > spells outs 3.x stuff, with indicators on package info pages and query > filters > on PyPI against that? I'm fine with adding more trove classifiers if that solves the problem (although I still assume the problem doesn't actually exist). As always, a classifier should not be added until there actually are two packages that want to use it. >> Can you kindly refer to some archived discussion for that? > > http://mail.python.org/pipermail/python-dev/2006-April/063943.html > > "I started looking at this. The number of complaints I > got when I started on this that it would break the > existing distutils based installers totally discouraged > me. In addition, the existing distutils codebase is ... > not good. > > It is flatly not possible to "fix" distutils and > preserve backwards compatibility." -Anthony Baxter Thanks. I still have the same position as I had then - if distutils is broken, it should be fixed, not ignored. > A controversial point, I'm afraid. Perhaps it is time for a parallel > rewrite, > so that those setup.py who import distutils get the old behavior, and those > who import distutils2 get the new, and we let attrition and the community > decide which is standard. Is there a list of the problems with distutils somewhere? It always worked fine for me, so I see no reason to fix it in the first place. Regards, Martin _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig