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

[Phillip J. Eby]

At 10:25 PM 10/6/2008 +0100, Floris Bruynooghe wrote:
>On Fri, Oct 03, 2008 at 12:35:11PM -0400, Phillip J. Eby wrote:
> > I'm thinking about putting together a pre-PEP for a "Build Utilities,
> > Installation Locations, & Distribution Standards" (BUILDS)
> > specification.
>
>Hehe, clever name!
>
> > The basic idea for the first PEP is to:
>[...]
> > 2. Comment on some lessons learned from the WSGI definition process and
> > WSGI in the field, and how they can be applied to the BUILDS process
>
>That will be interesting to read.  Not being a web developer I have no
>idea how WSGI came to be and what exactly it does.

WSGI came about because I was frustrated with the non-progress of the 
Web-SIG in creating standard request and response objects; it was 
quickly obvious to me that it would never go anywhere, due to 
socio/psych/economic considerations.  I proposed it in order to break 
the logjam by having a standard that more or less allowed everybody 
to do whatever they wanted and still be able to co-operate...  by 
arranging things so that the costs and benefits of adoption were 
balanced for all parties.

In the case of BUILDS, I propose to do the same: define a standard 
whose cost/benefit ratios are ideally balanced for each 
participant.  This does not, by the way, mean that everybody ends up 
with the same cost/benefit ratio; it simply means that the 
cost/benefit ratios are best for those people whose participation is 
most required for the standard to be widely adopted.

You can see that this is also what I did in the design of 
easy_install and setuptools, except that in that effort I only 
considered developers and users, not system packagers.  I propose to 
rectify that with BUILDS, although developers are still the most 
important audience a new standard must satisfy, in the sense that 
they require the best cost/benefit ratio for widespread adoption to 
occur.  (And this is of course in system packagers' best interest, 
since widespread adoption of the standard should make their lives 
easier, as long as the standard provides an improvement over the 
status quo for them.)

There are of course some other differences between this effort and 
those of WSGI and setuptools, but that's the 30-second summary.  :)


>[...]
> > 4. Lay out *non-goals* for the BUILDS project,
>[...]
> > or doing anything that requires
> > them to change the runtime contents of their projects (as opposed to
> > merely porting their setup.py, setup.cfg, etc.)
>
>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.

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.)


> > 5. Define rigorous terminology to be used for discussion of requirements
> > and design, including such terms as "project", "release", "distribution",
> > "system package", "installed distribution", etc.  (This is incredibly
> > important, because the discussions we're having now are already having
> > Tower-of-Babel confusions.)
>
>Yay, please make sure the terminology finally allows us to talk about
>packages in the .deb and .rpm meaning too.

The term I use for such packages is "system packages", btw.