I'm looking at PEP 426 specifications for installation hooks and wondering whether we need to tighten up the specification a little.
My concern stems from the fact that hook code needs to be installed along with other code - at least, the code for preuninstall hooks needs to be in the installed code. As it's "only" hook code, the naming of modules which contain it may not be done as carefully as the substantive modules and packages in a distribution. However, if multiple distributions were to put their hooks in a "hooks.py" module, which might seem the simplest thing to do, that could lead to problems: if these hook modules get written to site- packages, the hooks.py from a later installed distribution would override that from an earlier installed distribution. Possible solutions: 1. Constrain the specification so that each distribution must put hook code in a subpackage of one of their main packages. This will affect any distribution that consists only of modules and which has no packages, as the authors will have to create a package just for the hook code. 2. Constrain the specification so that hook code is segregated to a single module, perhaps specified by a "hook_module" key in the "install_hooks" dict, which is written to the .dist-info directory. An installer could add the .dist-info to sys.path before resolving/importing. The code in the hooks module could invoke any code it needed from the main body of code in the distribution. Is my concern a valid one? If so, can I please have comments/suggestions about how to address it? Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig