PEP 426 installation hooks and conventions
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
On 31 Jul 2013 08:49, "Vinay Sajip" <vinay_sajip@yahoo.co.uk> wrote:
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
It's installed along with everything else, why would anyone assume they can ignore naming conflicts? If they do, then it's either a bug or a mutual incompatibility between affected distributions (just like other accidental name conflicts). the
authors will have to create a package just for the hook code.
Why? If it's a single module that needs install hooks for some reason, the hook implementations can just go in there along with everything else (assuming they're not invoking a generic hook from a dependency). The names can be prefixed with an underscore to indicate they're not part of the regular API.
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?
Hook code is just normal code in the installed distribution (or a dependency). That's why there are deliberately no preinstall or postuninstall hooks - I don't want to come up with a new scheme for running code that hasn't been installed. Cheers, Nick.
Regards,
Vinay Sajip
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
participants (2)
-
Nick Coghlan
-
Vinay Sajip