Dne 13.8.2009 21:22, Brett Cannon napsal(a):

On Thu, Aug 13, 2009 at 11:23, Jan Matejek <jan.matejek@novell.com> wrote:

...

1 - the traditional way purelib = /usr/lib/pythonX.Y/site-packages platlib = /usr/lib(64)/pythonX.Y/site-packages

Why can't pure libraries go into lib64 as well? There is nothing saying that a pure Python package won't have a setup.py that installs different files based on whether it is for a 32-bit or 64-bit CPython install.

What i'd like to accomplish is to have pure "noarch" package that can be installed unchanged into 32bit or 64bit (or 256bit) system, and the respective python would still find the files. Or, to put it another way, a package that can be installed into a multiarch system and be recognized by pythons of all architectures (assuming they are the same version, of course). If the distutils package installs different pure files for 32bit and 64bit python, then it can't be "noarch", so it doesn't matter if it goes into lib64. Also, such package would break this particular scheme - in the situation where the user installs only 32bit version of such package and tries to run it with 64bit python, it will probably break in some weird way. Last but not least, i'd argue that if a python-only package installs different files for different platforms, it is platform-dependent and therefore not pure ;)

...

2 - the sharedir way purelib = /usr/share/python/X.Y platlib = /usr/lib(64)/pythonX.Y/site-packages

Now are you proposing that packages that have both Python source and extensions be split based on the type of files, or that only pure Python packages go to /usr/share/python and any packages that are mixed go into lib(64)? If you are proposing the latter this is more reasonable as the former will require using .pth files to get import to search both locations for files in the same package and that just feels icky to me.

The latter. Assume no change to "normal" distutils mechanism, only setting the default paths. (for now anyway) regards m.