The bug tracker for setuptools 0.7 or higher is on BitBucket



Title need support for post-install scripts
Priority wish Status chatting
Superseder Nosy List dpeterson, glyph, htgoebel, pje
Assigned To Keywords

Created on 2008-09-04.10:25:40 by htgoebel, last changed 2009-06-20.02:45:05 by pje.

msg313 (view) Author: pje Date: 2009-06-20.02:45:04
At 11:35 PM 6/19/2009 +0000, Glyph Lefkowitz wrote:
>the best way to handle these would be to put the install hooks 
>themselves into a
>library and install/invoke that via a data-driven hook.  But there 
>really needs
>to be more than a small fixed set of post-installation actions available, and
>some of these (i.e. computed registry keys) really do need the ability to pass
>in a small function.

Yes, I thought that was sort of implied in the previous 
discussion.  You could basically have a data structure for 
postinstall configuration, which would use entry points to do the 
mapping, and anything used would need to be an install-time 
dependency of the package being installed...  and the entry-point 
items would need to write out an installation log that would specify 
entry points and data to do the uninstall steps.

All in all, a pretty hefty set of requirements, and one that should 
probably be discussed on the SIG in the context of PEP 376, since 
there is some work being done towards uninstall support there.
msg312 (view) Author: glyph Date: 2009-06-19.23:35:06
pje, with regard to easy_install being for "libraries, not applications"; that
strikes me as untrue, although possibly just outdated given the time that
message was sent.  easy_install will happily install scripts.  More importantly,
applications (such as tahoe) are *trying* to use easy_install for their
installation :).

As far as data-driven post-install hooks, that sounds like a good idea to
prevent high variability in the way that common tasks are performed, and can be
made portable (installing shortcut icons, for example) but I doubt it's going to
be sufficient for a huge portion of post-installation requirements.  Assuming
that easy_install should handle applications, can we have purely data-driven
post install hooks for:

  * XDG menu entries
  * nautilus extensions
  * win32 shell extensions
  * win32 services
  * (x)inetd.conf server entries
  * unix init scripts
  * unix mail aliases
  * COM servers
  * konqueror extensions
  * deskbar plugins
  * twisted plugin cache generation
  * apache configuration
  * gnome panel applet registration
  * mac startup items, win32 startup items, XDG ~/.config/autostart

Keep in mind that one of your examples, registry keys, sometimes need to be
computed during installation rather than simply set to a static value.  Also,
this is an incomplete list that I could think of only in a moment.

In a sense, I agree that arbitrary code during installation is not optimal. 
This code should not all be inline at the bottom of some  Ultimately
the best way to handle these would be to put the install hooks themselves into a
library and install/invoke that via a data-driven hook.  But there really needs
to be more than a small fixed set of post-installation actions available, and
some of these (i.e. computed registry keys) really do need the ability to pass
in a small function.
msg311 (view) Author: glyph Date: 2009-06-19.23:13:54
Nobody has yet linked to the actual discussion where the decision was made, so
I'll take a stab at it.  Is this it?
msg310 (view) Author: pje Date: 2009-06-19.22:18:38
At 07:39 PM 6/19/2009 +0000, Dave Peterson wrote:
>glyph, what "prevented" it previously was a blanket rejection by PJE to add a
>generic post-install/pre-uninstall scripting capability.

Just for the record, it's only a rejection of fully generic 
scripting.  If somebody wants to define some sort of data-driven 
system for things like icons, docs, registry entries, and 
what-have-you, that'd be fine.
msg308 (view) Author: dpeterson Date: 2009-06-19.19:39:20
glyph, what "prevented" it previously was a blanket rejection by PJE to add a
generic post-install/pre-uninstall scripting capability.  And, honestly, I can
understand his reasons for doing so.  See the distutils-sig archives for that

However, we couldn't live without such a capability.  Now, at this point
approaching two years later, it's a little difficult to dig out a simple patch
for this feature from the Enstaller code.  That being said, Enstaller is an
open-source project and you're welcome to browse the source distribution from
PyPi or browse the codebase through Trac at in order to see what
we've done.
msg307 (view) Author: glyph Date: 2009-06-19.18:02:25
dpeterson, if you'd like to contribute your efforts to an existing project, what
has prevented you from attaching your post-install support patches here? ;-) 
Would you please attach them to this ticket, so that those of us who need the
feature can agitate to get them included?
msg306 (view) Author: dpeterson Date: 2009-06-19.16:43:19
For the record, having this feature would have been of great benefit when
creating EPD (the Enthought Python Distribution).  As it is, we've had to create
alternative install tools (see Enstaller's patched version of setuptools source,
plus its enpkg and egginst tools).  We would have much rather contributed our
efforts to an existing project but just couldn't wait for this type of feature
to appear.
msg258 (view) Author: glyph Date: 2009-04-03.18:20:18
Also, note that any project which _uses_ the Twisted plugin system (i.e. nevow,
axiom) will have the same problem, because it needs to re-generate the cache
which twisted generated when it was installed.
msg257 (view) Author: glyph Date: 2009-04-03.18:17:23
The lack of a post-installation hook of any kind effectively prevents Twisted
from releasing eggs.

Our plugin system functions by having a 'twisted/plugins' package where multiple
projects install .py files.  As described in
for reasonable performance (and to avoid unnecessary imports at runtime) we need
to write a cache when new .py files are installed into that location.  In the
case where the administrator is installing new python packages we _really_ need
to do it at install time, because an application not running as the
administrator won't have write access to the plugin directory.
msg174 (view) Author: htgoebel Date: 2008-09-17.08:29:10
Regarding the win32 install: This does _not_ only affect the COM objects. The
post-install script also installs some required dlls. Thus the missing support
for post-install scripts effects "normal" applications like py2exe or bb_freeze.
msg164 (view) Author: pje Date: 2008-09-11.15:35:21
This is a feature, not a bug.  Reclassifying status to "wish" since no
acceptable designs for this feature have yet been proposed.  (See distutils-sig
archives for previous discussions.)

(Also, the only part of pywin32 installation affected by the post-install script
is the ability to properly register and implement COM objects in Python; i.e.,
it only affects the ability of non-Python programs to invoke Python COM objects.
 Any application that requires this feature is probably going to need more
installation-time support than just an easy_install post-install script.)
msg156 (view) Author: htgoebel Date: 2008-09-04.10:31:11
Setting higher priority since pywin32 is affected which is a key application.
msg154 (view) Author: htgoebel Date: 2008-09-04.10:25:39
easy_install needs some mechanism for running post-installation scripts. This is
required by eg. pywin32 (see issue18) and py2exe. If uninstall is implemented
(see issue21), pre-/post-uninstall scripts need to be supported, too.

I suggest adding new entry-points:
- easy-install.pre-uninstall

(pre-install does not make sense, since typically the package can not be used
prior to installation :-)
Date User Action Args
2009-06-20 02:45:05pjesetmessages: + msg313
2009-06-19 23:35:08glyphsetmessages: + msg312
2009-06-19 23:13:54glyphsetmessages: + msg311
2009-06-19 22:18:38pjesetmessages: + msg310
2009-06-19 19:39:20dpetersonsetmessages: + msg308
2009-06-19 18:02:25glyphsetmessages: + msg307
2009-06-19 16:43:19dpetersonsetnosy: + dpeterson
messages: + msg306
2009-04-03 18:20:18glyphsetmessages: + msg258
2009-04-03 18:17:23glyphsetnosy: + glyph
messages: + msg257
2008-09-17 08:29:10htgoebelsetmessages: + msg174
2008-09-11 15:35:21pjesetpriority: urgent -> wish
nosy: + pje
messages: + msg164
2008-09-04 10:31:11htgoebelsetpriority: feature -> urgent
status: unread -> chatting
messages: + msg156
2008-09-04 10:25:40htgoebelcreate