[Distutils] Pre-pre-PEP: Requirements for the Python BUILDS Specification

[Phillip J. Eby]

At 09:57 AM 10/7/2008 +0200, Josselin Mouette wrote:
>Le lundi 06 octobre 2008 à 21:33 -0400, Phillip J. Eby a écrit :
> > >Does this mean actively avoiding an API that would allow developers to
> > >access certain types of data files (I'm thinking of the discussion
> > >about locale data and not putting anything else but .py/.pyc/.pyo
> > >files in packages) or merely making sure the existing way (of shipping
> > >data files in packages and finding them by os.path and __file__) keeps
> > >working?
> >
> > I would actively avoid it for a "BUILDS 1.0" spec, because on any
> > platform where the people building installation tools care about
> > relocating these files, symlinks are available, so both sides can be
> > happy without needing a new API.
>
>I fail to see what this would bring over the current situation, then.
>
> > That is, unless I have misunderstood Josselin and Toshio, I
> > understand symlinks to currently be an acceptable compromise.  (For
> > example, Debian uses them to relocate .pyc files currently.)
>
>Symlinks are a real pain to handle. We can use them transparently
>for .pyc files, but if we want to relocate data files to some other
>directories, currently it has to be done by hand, and this is why most
>maintainers don’t do it.

Which is why the idea for the BUILDS spec to include a way for 
automated tools to do it, so that you won't have to do it manually.

Or are you saying that that isn't an improvement over the current situation?

Yes, it's true that I'm saying that developers should not be 
*required* to add the extra data to their packages, but that they 
should be *able* to, and if it is trivial to add the extra data, most 
should accept patches or respond to requests to do so.

Right now, it's not even *possible* for them to do so, however.

Also, I wasn't aware of those peculiarities regarding Twisted and 
GStreamer -- neither one uses setuptools.  But certainly they should 
make interesting test cases for any proposed standard, wrt to finding 
ways to satisfy both parties.

Please understand that I'm not saying we must be 100% backward 
compatible with 100% of the packages; we just need to be compatible 
enough with enough of the packages for network effects to drive the 
adoption of the rest.

At the same time, the people I'd most like to see on the PEP team 
from the developer-user side would definitely include folks from 
Twisted, Numpy, Enthought, and Zope, as they are the folks who have 
most stressed the distutils to the limits and beyond.  Just getting 
you and them in the "same room" so to speak seems to already be 
producing some benefits.