How to make easy_install execute custom commands in setup.py?

Question

I want my setup.py to do some custom actions besides just installing the Python package (like installing an init.d script, creating directories and files, etc.) I know I can customize the distutils/setuptools classes to do my own actions. The problem I am having is that everything works when I cd to the package directory and do "python setup.py install", but my custom classes don't seem to be executed when I do "easy_install mypackage.tar.gz". Here's my setup.py file (create an empty myfoobar.py file in the same dir to test):

import setuptools
from setuptools.command import install as _install

class install(_install.install):
    def initialize_options(self):
        _install.install.initialize_options(self)

    def finalize_options(self):
        _install.install.finalize_options(self)

    def run(self):
        # Why is this never executed when tarball installed with easy_install?
        # It does work with: python setup.py install
        import pdb;pdb.set_trace()
        _install.install.run(self)

setuptools.setup(
    name = 'myfoobar',
    version = '0.1',
    platforms = ['any'],
    description = 'Test package',
    author = 'Someone',
    py_modules = ['myfoobar'],
    cmdclass = {'install': install},
)

The same thing happens even if I import "setup" and "install" from distutils. Any ideas how I could make easy_install execute my custom classes?

To clarify, I don't want to use anything extra, like Buildout or Paver.

Answer 1

Paver takes setuptools to the next level and lets you write custom tasks. It allows you to extend the typical setup.py file and provides a simple way to bootstrap the Paver environment.

Answer 2

It cannot be done. Enthought has a custom version of setuptools that does support this, but otherwise it is in the bug tracker as a wishlist item that has been under discussion since June.

However, there are ways to trick the system and you might consider them. One way is to have your most important module, the one that is always imported first when using your package, do the post install actions the first time it is called. Then you have to clean up after yourself, and consider the case where you cannot write into the library because an admin installed the package and the first user is someone other than admin.

In the worst case, this would involve creating a ~/.mypackage directory for ever user who uses the package, and rerunning the postinstall once for each new user. Every time the module is imported, it checks for the existence of ~/.mypackage. If it is not there, it runs the postinstall and creates it. If it is there, it skips the postinstall.