[Distutils] Timeframe of 2.0 again?
Mark W. Alexander
mwa at anonymoose.net
Mon Oct 27 22:37:20 EST 2003
On Mon, 27 Oct 2003, Moore, Paul wrote:
> > Right. We are adding many features to distutils which we
> > need for supporting features like, e.g. automatic configuration,
> > etc. These features rely heavily on subclassing and the
> > way distutils is tied together. Supporting the more than
> > 5 versions out there is not feasable in this kind of setup
> > which is typical of distutils packaging, since distutils
> > is designed to be extended in this way.
> OK, so you are talking about compatibility at the setup.py level.
> In that case, I agree entirely - whatever changes are made to
> distutils should be done very carefully to avoid breaking existing
> setup.py scripts.
That's my concern as well.
> Having said that, it would be nice if the distutils documentation
> was complete enough that it was feasible to say "we reserve the
> right to break anything that isn't documented". In many ways,
> that should be the number 1 priority for distutils, complete
> documentation of the API.
Amen. But until the API is fully documented there are a lot of, uhm,
"creative" setup.py's out there.
> I'd imagine that there is a nasty grey area where seriously complex
> setup.py scripts will need to be deemed as "getting too chummy with
> the internals", and breakage will be necessary. Maybe there's a
> need for a staged approach (lots more documentation, plus some
> official deprecation - for example, things like fancy_getopt - in
> 2.4, with the API cleanup being left to 2.5).
Those "seriously complex" setup.py scripts are a great place to get
ideas about what features package authors really need in Distutils2.
Anything that looks "too chummy" means there probably needs to be a more
abstract method to accomplish what's being done.
Mark W. Alexander
slash at dotnetslash.net
More information about the Distutils-SIG