(original) (raw)

- I reject setup.cfg, as I believe ini-style configuration files are

not appropriate for a metadata format that needs to include file

listings and code fragments

- I reject bento.info, as I think if we accept

yet-another-custom-configuration-file-format into the standard library

instead of just using YAML, we're even crazier than is already

apparent

- I shall use "dist.yaml" as my proposed name for my "I wish I could

define packages like this" format (and yes, that means adding yaml

support to the standard library is part of the wish)

- many of the details below will be flawed, but I want to give a clear

idea for how a concept like this might work in practice

- we need to define a clear set of build phases, and then design the

dist metadata format accordingly. For example:

- source

- uses a "source" section in dist.yaml

- "source/install" maps source files directly to desired

install locations

- essentially what the setup.cfg Resources section tries to do

- used for pure Python code, documentation, etc

- See below for example

- "source/files" defines a list of extra files to be included

- "source/exclude" defines the list of files to be excluded

- "source/run" defines a Python fragment to be executed

- serves a similar purpose to the "files" section in setup.cfg

- creates a temporary directory (and sets it as the working directory)

- dist.yaml is copied to the temporary directory

- all files to be installed are copied to the temporary directory

- all extra files are copied to the temporary directory

- the Python fragment in "source/run" is executed (which can

thus easily add more files)

- if sdist archive creation is requested, entire contents of

temporary directory are included

- build

- uses a "build" section in dist.yaml

- "build/install" maps built files to desired install locations

- like source/install, but for build artifacts

- compiled C extensions, .pyc and .pyo files, etc would all go here

- "build/run" defines a Python fragment to be executed

- "build/files" defines the list of files to be included

- "build/exclude" defines the list of files to be excluded

- "build/requires" defines extra dependencies not needed at runtime

- starting environment is a source directory that is either:

- preexisting (e.g. to allow building in-place in the source tree)

- created by running source first

- created by unpacking an sdist archive

- the Python fragment in "build/run" is executed to trigger the build

- if the build succeeds (i.e. doesn't throw an exception)

- create a temporary directory

- copy dist.yaml

- copy all specified files

- this is the easiest way to exclude build artifacts from

the distribution, while still keeping them around to enable

incremental builds

- if bdist\_simple archive creation is requested, entire

contents of temporary directory are included

- other bdist formats (such as bdist\_rpm) will have their own

rules for getting from the bdist\_simple format to the platform

specific format

- install

- uses an "install" section in dist.yaml

- "install/pre" defines a Python fragment to be executed

before copying files

- "install/post" defines a Python fragment to be executed

after copying files

- starting environment is a bdist\_simple directory that is either:

- preexisting (e.g. to allow creation by system packaging tools)

- created by running build first

- created by unpacking a bdist\_simple archive

- end result is a fully installed and usable piece of software

- test

- uses a "test" section in dist.yaml

- "test/run" defines a Python fragment to be executed to start the tests

- "test/requires" defines extra dependencies needed to run the

test suite