[Distutils] PEP 426 installation hooks and conventions

Nick Coghlan ncoghlan at gmail.com
Wed Jul 31 01:05:09 CEST 2013

On 31 Jul 2013 08:49, "Vinay Sajip" <vinay_sajip at 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.

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).

>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
> 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
> 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
> 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
> 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.


> Regards,
> Vinay Sajip
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130731/3a973fef/attachment.html>

More information about the Distutils-SIG mailing list