[Distutils] Pre-pre-PEP: Requirements for the Python BUILDS Specification

[Josselin Mouette]

Le lundi 06 octobre 2008 à 21:33 -0400, Phillip J. Eby a écrit :
> >Does this mean actively avoiding an API that would allow developers to
> >access certain types of data files (I'm thinking of the discussion
> >about locale data and not putting anything else but .py/.pyc/.pyo
> >files in packages) or merely making sure the existing way (of shipping
> >data files in packages and finding them by os.path and __file__) keeps
> >working?
> 
> I would actively avoid it for a "BUILDS 1.0" spec, because on any 
> platform where the people building installation tools care about 
> relocating these files, symlinks are available, so both sides can be 
> happy without needing a new API.

I fail to see what this would bring over the current situation, then.

> That is, unless I have misunderstood Josselin and Toshio, I 
> understand symlinks to currently be an acceptable compromise.  (For 
> example, Debian uses them to relocate .pyc files currently.)

Symlinks are a real pain to handle. We can use them transparently
for .pyc files, but if we want to relocate data files to some other
directories, currently it has to be done by hand, and this is why most
maintainers don’t do it.

Furthermore, you seem to be unaware of the amount of abuse that was
produced by the mere idea of using __file__ to locate data. It is not
only about loading a few image files, let me show you some cases.

Case 1: pastescript. This module ships templates of python modules, that
are named with the .py extension but are not usable as is from the
interpreter, and shipped in the modules directory. How in the world can
our tools know that they shouldn’t be byte-compiled and that they should
be relocated to somewhere in /usr/share/$package?

Case 2: twisted. Plugins, consisting of a few .py files, are shipped in
a plugins/ subdirectory, and its content is dynamically added to
sys.path after some sanity checks (which fail when you add namespace
packages). The reason is to allow plugins for several incompatible
Twisted versions to be installed in the *same* directory. When there are
solutions as simple as versioning the plugin directory, I can’t
understand how people can think of (and implement) such broken
solutions.

Case 3: GStreamer. The modules installation directory is detected at
compile time and then hardcoded in the modules themselves so that some
subdirectories can be added to sys.path upon loading. In the end, the
modules are not relocatable.

I keep wondering what Python module developers will invent next to
complicate packaging even more. Frankly, we’d lose much less hair if
such things were simply impossible. At least, it should be documented
that such practice is wrong, so that we can actually consider it buggy
and make our tools simpler.

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20081007/265bedcd/attachment.pgp>