[Distutils] Supporting extensibility in disutils

[Fred L. Drake, Jr.]

On Monday 02 August 2004 12:49 pm, M.-A. Lemburg wrote:
 > I'm +1 on being able to *add* new commands this way, but a
 > strong -1 on overriding distutils own commands by doing
 > import hackery. The reason for the latter is that tracking down
 > errors in such setups is a complete nightmare - both for the
 > developer and the user.

I'm not actually suggesting any import hackery that isn't being done already.  
All that's being done is loading of a class from a computed name; I'm 
suggesting that distutils try more than one name before failing.

I don't think the package developer should need to worry about such setups at 
all.  If they provide a setup.py that works with a vanilla Python, they've 
done their part.  It's the responsibilty of the distutils extension developer 
to work with what they get.

 > How about something like a PYTHONDISTUTILSPATH + distutils.path
 > (mimicing PYTHONPATH and sys.path for command lookups) ?

That would certainly work for adding commands.  I'm not convinced we don't 
want to allow overrides, though.  (No, I don't like that directories from 
PYTHONPATH come after the default path, or that site-packages comes after the 
standard library.)  We could certainly point out the potential dangers of 
overriding stock commands in this way, but it's not clear that we need to 
disallow overriding either.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>