On 6/24/2010 5:09 PM, Barry Warsaw wrote: >> What use case does this address? > > Specifically, it's the use case where we (Debian/Ubuntu) plan on installing > all Python 3.x packages into /usr/lib/python3/dist-packages. As of PEP 3147, > we can do that without collisions on the pyc files, but would still have to > symlink for extension module .so files, because they are always named foo.so > and Python 3.2's foo.so won't (modulo PEP 384) be compatible with Python 3.3's > foo.so.
If the package has .so files that aren't compatible with other version of python, then what is the motivation for placing that in a shared location (since it can't actually be shared)? > So using the same trick as in PEP 3147, if we can name Python 3.2's foo > extension differently than the incompatible Python 3.3's foo extension, we can > have them live in the same directory without symlink tricks. Why would a symlink trick even be necessary if there is a version-unspecific directory and a version-specific directory on the search path? >> PEP 3147 addresses the fact that the user may have different versions of >> Python installed and each wants to write a .pyc file when loading a module. >> .so files are not generated simply by running the Python interpreter, ergo >> .so files are not an issue for that use case. > > See above. It doesn't matter whether the pyc or so is created at run time by > the user or by the distro build system. If the files for different Python > versions end up in the same directory, they must be named differently too. But the only motivation for doing this with .pyc files is that the .py files are able to be shared, since the .pyc is an on-demand-generated, version-specific artifact (and not the source). The .so file is created offline by another toolchain, is version-specific, and presumably you are not suggesting that Python generate it on-demand. > >> If you want to make it so a system can install a package in just one >> location to be used by multiple Python installations, then the version >> number isn't enough. You also need to distinguish debug builds, profiling >> builds, Unicode width (see issue8654), and probably several other >> ./configure options. > > This is a good point, but more easily addressed. Let's say a distro makes > three Python 3.2 variants available, one "normal" build, a debug build, and > UCS2 and USC4 versions of the above. All we need to do is choose a different > .so ABI tag (see previous follow) for each of those builds. My updated patch > (coming soon) allows you to define that tag to configure. So e.g. Why is this use case not already addressed by having independent directories? And why is there an incentive to co-mingle these version-punned files with version-agnostic ones? > Mix and match for any other build options you care about. Because the distro > controls how Python is configured, this should be fairly easy to achieve. For packages that have .so files, won't the distro already have to build multiple copies of that package for all version of Python? So, why can't it place them in separate directories that are version-specific at that time? This is not the same as placing .py files that are version-agnostic into a version-agnostic location. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
