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.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
