[Distutils] EasyInstall --> distutils command + setuptools enhancements?
Phillip J. Eby
pje at telecommunity.com
Wed Jun 8 19:21:30 CEST 2005
At 12:05 PM 6/8/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>As I move towards implementing features for EasyInsall like having
>>distutils-style configuration files, and refactoring the 'main()'
>>function for reusability and extension by other packages, I began to
>>notice something: I was basically reinventing a distutils Command object.
>Are you thinking solely about a two-level command? It's a little
>confusing, because it seems like EasyInstall and distutils are kind of
>separate, and I'm not clear what relation you are proposing.
>If it's just that there be two levels to the command, just like in
>distutils or cvs, among other commands, then yes, I think that's a good
>idea, and I can imagine quite a few commands over time.
>As for the specific implementation, I don't know that distutil's Command
>is worth using if it's outdated.
Yes, but it *integrates* with existing functionality, which is useful. It
would also make it easier for setup scripts to use EasyInstall
functionality as part of their build process.
>>So what are the downsides to this, apart from needing to turn lots of
>>little methods into entire Command subclasses? Well, I imagine it makes
>>it harder for somebody to build-in the commands to non-distutils
>>programs, unless there's an easy way to create and run the commands, like
>>if I added a class method like 'invoke(**args)' to a base class, so that
>>you could say stuff like 'package.download_url.invoke(url="whatever")' in
>>order to call 'em from inside the program. I've already added something
>>similar to the 'bdist_egg' comamnd called 'call_command(name,**args)', so
>>that you can more easily invoke other commands as subroutines.
>Would it make more sense to just keep the command-line interface down to a
>thin wrapper around module-level functions?
Well, the argument metadata still has to exist somewhere. And most of the
functions would end up needing to have access to various data items. The
structure definitely mimics the structure of the distutils commands, and it
seems silly to go off and create another framework, especially since I
already have to import the distutils anyway.
More information about the Distutils-SIG