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

Phillip J. Eby pje at telecommunity.com
Fri Oct 3 18:35:11 CEST 2008


I'm thinking about putting together a pre-PEP for a "Build Utilities, 
Installation Locations, & Distribution Standards" (BUILDS) 
specification.  But first, I want to throw out a few ideas to test 
the waters, and to give a general idea of what the first PEP would cover.

The basic idea for the first PEP is to:

1. Give an overview of the current situation (problems w/distutils 
and setuptools, mainly, but also some of the successes)

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

3. Lay out high-level goals for the BUILDS project, such as:

    * distributing responsibility/authority for build tools development
    * adding extensibility to installation processes,
    * providing a 100% open playing field for build & install tools,
    * interoperability with the existing "egg" infrastructure, and
    * interoperability (but not 100% backward-compatibility) with distutils
    * allowing an incremental transition to the new standard

4. Lay out *non-goals* for the BUILDS project, such as trying to get 
developers to become system packagers 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.), defining and 
implementing the "perfect" system, etc.

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

6. Sketch an overall design concept (build libraries in the stdlib 
establishing a Python API for invoking build tools, that in turn 
build an installation manifest to be used by installation tools), but 
without specifying actual APIs, manifest format, or a full 
enumeration of release metadata.

7. Present a vision/plan for how migration can occur from current tools.

8. Set the scope for the PEPs that should follow, on the installation 
manifest format, build architecture, build tool API, compiler/config 
infrastructure, etc.

Whew.  As you can see, just defining the problem adequately is a big 
job, and it may take a while to get even this first PEP right.  So, 
I'd like some feedback, if anybody has some ideas about what else 
needs to be added to this.

I also don't want to end up writing all of the PEPs, or else it may 
be a year or so before they all get done.  ;-)  I also think we're 
going to want a working group for this, or maybe multiple working 
groups, and it might be best not to use the general distutils-SIG for 
discussion past the first PEP, to allow people to filter threads better.

Anyway.  Thoughts, comments, volunteers, anyone?



More information about the Distutils-SIG mailing list