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.
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
