[Distutils] Removing the hack from setup.py - Setup.py as a Class, not a Procedure

[David Lyon]

On Tue, 21 Jul 2009 14:12:48 -0400, "P.J. Eby" <pje at telecommunity.com>
wrote:
> The concept of "package data" is data in the same directory as the 
> package's Python code.  Using it to install libraries is a bit of a 
> hack in the first place.

Too right it's a hack - haha. I'm glad that I'm not the only one who's 
noticed.

As a relative newcomer I can see how setup.py might have been "advanced"
in the good old days..

Now it's somewhat restrictive. And my guess + experience is that it
can take about 3+ days to get a "typical" setup.py to work properly
because of all the hacks. (For a newcomer)

My constructive suggestion for making setup.py more "friendly"
would be to update it Object Oriented technology. Along the 
following lines:

 1) Extend setup.cfg to hold more/all-of the metadata

 2) Turn 'setup' into a class (rather than a procedure)

 3) Provide a 'user' area/function like say 'pre-setup'
    "self.pre_setup()" that is a method that gets run 
    before the actual 'setup' method.

    This 'self.pre_setup()' method gets provided with a whole
    lot of information about where everything will go.

    ie.. the destination directory (self.destination?)
         operating system (self.os_name)
         window manager (self.window_manager)
         location of script directories (self.scripts)
         location of data directories (self.data_dir)
         location of docs directories (self.doc_dir)
         a pulldown menu object (for adding shortcuts)
         a desktop object (for adding shortcuts)
         list of python packages already installed (self.packages)
         information about the web environment (self.web_environment)

    When the "self."* properties are then all adjusted
    the code can proceed to the 'self.setup()' method
    where the actual install can be done.

 4) Provide a 'user' area/function like say post-setup
    "self.post_setup() that gets run after the 'self.setup()'.

    This then gives the application a chance to do post
    setup initialisation. Modifying attributes, registering
    libraries, generating documentation... whatever

This would preserve the "idea" of setup.py but give it more
real world information allowing its use to be less obscure.

We could modernise setup.py with this approach and allow
it to be a very good cross platform tool....

David