Since you can easily read the PEP at
https://github.com/brettcannon/build-deps-pep in a nice, rendered format I
won't repost the whole thing, but here are the changes I have made based on
the comments so far.
1. I rephrased throughout the PEP to not explicitly say this is for
building wheels (for Robert). I was just trying to tie the PEP into what
happens today, not what we plan to have happen in the future.
2. Fixed the quotation marks on the TOML examples (for Nathaniel). It's
just habit from Python why I did it the way I did.
3. Reworked the Abstract to the following (for Robert):
"""
This PEP specifies how Python software packages should specify what
dependencies they have in order to execute their chosen build system.
As part of this specification, a new configuration file is introduced
for software packages to use to specify their build dependencies (with
the expectation that the same configuration file will be used for
future configuration details).
"""
4. Added a bit to the end of the Rationale section about where this fits in
future plans (for Robert):
"""
To provide more context and motivation for this PEP, think of the
(rough) steps required to produce a built artifact for a project:
1. The source checkout of the project.
2. Installation of the build system.
3. Execute the build system.
This PEP covers step #2. It is fully expected that a future PEP will
cover step #3, including how to have the build system dynamically
specify more dependencies that the build system requires to perform
its job. The purpose of this PEP though, is to specify the minimal set
of requirements for the build system to simply begin execution.
"""
5. Added a JSON Schema for the resulting data (for Nick because he must be
writing a lot of specs at work recently if he needs typing information for
2 fields :). This is based on Nathaniel's initial work, but I made the
"requires" key a requirement when [package.build-system] is defined. I did
not change the name of the key to "schema-version" for the reasons
Nathaniel outlined in his response to Nick on the topic.
{
"$schema": "http://json-schema.org/schema#";,
"type": "object",
"additionalProperties": false,
"properties": {
"package": {
"type": "object",
"additionalProperties": false,
"properties": {
"semantics-version": {
"type": "integer",
"default": 1
},
"build-system": {
"type": "object",
"additionalProperties": false,
"properties": {
"requires": {
"type": "array",
"items": {
"type": "string"
}
}
},
"required": ["requires"]
}
}
},
"tool": {
"type": "object"
}
}
}
I didn't add an example using 'distutils.numpy' as Nick asked because it's
just the same example as in the PEP but with one field changed; IOW it
doesn't really add anything. I also didn't rename the file as Randy argued
for because the file is for the project, not just the package(s) the
project contains ("package" is an overloaded term and I don't want to
contribute to that with the filename; I can live with the build details
being in relation to a package in the project and thus named [package], but
other things that may end up in this file might not relate to any package
in the project).
On Tue, 10 May 2016 at 17:39 Brett Cannon <br...@python.org> wrote:
> Donald, Nathaniel, and I have finished our proposed PEP for specifying a
> projects' build dependencies. The PEP is being kept at
> https://github.com/brettcannon/build-deps-pep, so if you find spelling
> mistakes and grammatical errors please feel free to send a PR to fix them.
>
> The only open issue in the PEP at the moment is the bikeshedding topic of
> what to name the sub-section containing the requirements: `[package.build]`
> or `[package.build-system]` (we couldn't reach consensus among the three of
> us on this). Otherwise the three of us are rather happy with the way the
> PEP has turned out and look forward to this being the first step towards
> allowing projects to customize their build process better!
>
So far the votes for this open issue are:
build-system:
1. Nathaniel
2. Ian
3. Ethan
4. Nick
5. Paul
build:
1. Donald
2. Daniel
build-configuration (write-in candidate):
1. Antoine
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
