At 01:32 PM 7/21/2006 -0700, Andrew Straw wrote: >Upon re-reading the new Debian python policy, I see that the idea of >having .py files installed in one tree for multiple python versions is >optional (albeit "strongly encouraged" as stated at >http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html). >So, I can personally continue to ignore this supposedly optional aspect >of the new Debian Python policy, but I don't know for how long. For >example, recent discussions on the debian-python list suggest to me that >the use of this new policy is very strongly encouraged rather than >merely "optional".
I read the entire policy you linked to, and I don't actually see many problems. It seems to me that the single largest problem in that policy is that it clearly predates the existence of the distutils. It has no conception of a Python *project* or *distribution*, only modules and packages. It's therefore not surprising that it also doesn't encompass such issues as distribution metadata, package data, namespace packages, and the like. It also explains why the policy is so out-of-sync with e.g. PyPI. (I hesitate to see what would happen if somebody tries to package any of my Python projects such as SymbolType or ProxyTypes for Debian: they all are modules in the 'peak' package, but each is distributed as a separate project!) From the extremely limited conceptual position that only modules and packages exist, it's also impossible to understand how you can have different versions of things for different versions of Python, because everything is defined in terms of the modules! However, project distributions are merely *composed* of modules, and what modules get installed (or what distribution metadata is generated) may depend on the Python version. The same project may also have different dependencies, depending on the Python version. These concepts can't be well-understood from the perspective that only modules and packages exist, so until the policy's conceptual underpinning is expanded, it's going to continue to be difficult to squeeze square pegs into the policy's round holes. >So, to ask your advice, then, how would _you_ suggest stdeb install >Python packages using the Debian system? Plain old >"--single-version-externally-managed" without any .egg-info directory >renaming? That would be simple enough for me... That is what I would recommend, yes. Installed, of course, to the standard Python directories, rather than to a shared one, since that would lead to conflicts when alternate versions exist. I don't know enough about Debian to know what it does with package naming, but I do know that e.g. NetBSD package naming conventions include the Python version for which a project is packaged, such that you could have py22-foo, py23-foo, and py24-foo of the same project "foo". IMO, any other way of doing it is an accident waiting to happen... or else a "job security" bonus for the people who write the tools and fix the problems. I guess it's always better to look at it from the bright side. ;) _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
