
David Cournapeau wrote:
Toshio Kuratomi wrote:
Tarek Ziadé wrote:
Hello,
This is a side discussion but quiet important ihmo.
== Problem ==
Some people complained about the fact that is was hard to extend Distutils commands. You end up rewriting the whole command most of the time.
So what's a command ? It's a class that is used by the distribution instance when you run Distutils.
roughly:
cmd = Command(distribution) cmd.initialize_options() cmd.finalize_options() <--- allows to check the options if subcommands where run cmd.run() <--- runs the code
each command can define sub commands, but most of the time it's a harcoded list, so you need to inherit the command if you want to add a new behavior.
== work in progress, ==
What we want to do here is being able to define subsets in run(), sharing the same options environment.
so basically, a rough, generic run() method could be:
def run(): for func in some_funcs: func(self, options)
If "some_funcs" could be defined by a registery with simple names, anyone could provide new functions and configure the registery to run a sequence of function.
Given a command name, Distutils can get this list of function, through a registery. Each function could register itself into Distutils, like in what I have started to work here for the manifest file: see http://wiki.python.org/moin/Distutils/ManifestPluginSystem
The ordering would be configurable through the setup.cfg file.
Any opinion, idea for this part ?
Have you looked at paver? It's syntax makes extension easy.
Yes, paver is nice, but I don't think it solves the problem that Tarek aimed at solving here. Let me introduce some usercases. For example, if you want to extend say the distutils sdist command, you could do:
@task @needs(['distutils.command.sdist']) def mysdist(): # Add some more stuff here to the tarball ...
But what if you want to alter the original sdist behavior, e.g. place some files elsewhere ? Paver works nice if you want to extend the existing behavior in a simple way (after doing this, do that), but unfortunately, some things do not fit well if at all in this scheme.
@task @needs(['distutils.command.sdist']) def sdist(): # Place some files in an alternate location
I would cite two examples, related to sdist and paver: - http://groups.google.com/group/paver/browse_thread/thread/581534ca19cc541e - http://groups.google.com/group/paver/browse_thread/thread/e153ba3da8cc3334
those are both bugs in paver. (Whether they're resolvable or not within paver, I don't know.) They don't have bearing on talking about redesigning how to design a new architecture that's easy to extend. -Toshio