Removing the aspirational aspects of PEP 426
From an sdist metadata perspective, though, I think the right thing to do is to descope PEP 426 to just the stuff we *need* for the build system improvements, and defer everything else (e.g. JSON-LD, SPDX, richer dependency semantics, etc) to a future metadata 3.0 proposal (or
Caught up on distutils-sig this morning - I don't have any additional comments on Robert's and Nathaniel's draft PEPs except to say "I really like the look of where they're going, and look forward to reading the next iterations on them that take into account the feedback already received" :) The idea of treating extras as subdistributions with their own wheel metadata also sounds promising (and analogous to building multiple binary RPMs from a single source RPM). potentially metadata extensions, or 2.x format updates). The one major enhancement I think would be worth keeping is the metadata extension system (including mandatory extension support), since that provides a way to experiment with ideas that we may later standardise in 3.0. I'm not sure when I'd have time to work on that myself though, so I'm definitely open to expressions of interest in taking a hatchet to the PEP. Nathaniel, Robert, perhaps you'd be interested in that as part of the build interface standardisation? Regards, Nick.
On Oct 28, 2015 3:25 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
From an sdist metadata perspective, though, I think the right thing to do is to descope PEP 426 to just the stuff we *need* for the build system improvements, and defer everything else (e.g. JSON-LD, SPDX, richer dependency semantics, etc) to a future metadata 3.0 proposal (or
[...] potentially metadata extensions, or 2.x format updates). I think PEP 426 is actually orthogonal to these proposals. AFAICT, the only reason Robert's PEP as written requires PEP 426 is that he needs a standard serializable format to list dependencies... but he actually defines such a format about 10 lines above for the static bootstrap-requirements key, i.e. a list of specifier strings. So it actually makes more sense to use that for dynamic requirements too for internal consistency, and leave PEP 426 out of it. -n
On 28 Oct 2015 11:39, "Nathaniel Smith" <njs@pobox.com> wrote:
On Oct 28, 2015 3:25 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
[...]
From an sdist metadata perspective, though, I think the right thing to
do is to descope PEP 426 to just the stuff we *need* for the build system improvements, and defer everything else (e.g. JSON-LD, SPDX, richer dependency semantics, etc) to a future metadata 3.0 proposal (or potentially metadata extensions, or 2.x format updates).
I think PEP 426 is actually orthogonal to these proposals. AFAICT, the
only reason Robert's PEP as written requires PEP 426 is that he needs a standard serializable format to list dependencies... but he actually defines such a format about 10 lines above for the static bootstrap-requirements key, i.e. a list of specifier strings. So it actually makes more sense to use that for dynamic requirements too for internal consistency, and leave PEP 426 out of it. If you can avoid blocking on metadata 2.0 entirely, that's even better :) Cheers, Nick.
-n
On 28 October 2015 at 23:39, Nathaniel Smith <njs@pobox.com> wrote:
On Oct 28, 2015 3:25 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
[...]
From an sdist metadata perspective, though, I think the right thing to do is to descope PEP 426 to just the stuff we *need* for the build system improvements, and defer everything else (e.g. JSON-LD, SPDX, richer dependency semantics, etc) to a future metadata 3.0 proposal (or potentially metadata extensions, or 2.x format updates).
I think PEP 426 is actually orthogonal to these proposals. AFAICT, the only reason Robert's PEP as written requires PEP 426 is that he needs a standard serializable format to list dependencies... but he actually defines such a format about 10 lines above for the static bootstrap-requirements key, i.e. a list of specifier strings. So it actually makes more sense to use that for dynamic requirements too for internal consistency, and leave PEP 426 out of it.
pip requires: - distribution name - install_requires [+extras] today. It will want external dependencies in future (and in the spec I put forward build dependencies would be obtained earlier so could be skipped). I'd rather not invent a *new* format for handling both of these, but i'm ok if Donald and Nick specifically are. -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
On 29 October 2015 at 02:09, Robert Collins <robertc@robertcollins.net> wrote:
On 28 October 2015 at 23:39, Nathaniel Smith <njs@pobox.com> wrote:
On Oct 28, 2015 3:25 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
[...]
From an sdist metadata perspective, though, I think the right thing to do is to descope PEP 426 to just the stuff we *need* for the build system improvements, and defer everything else (e.g. JSON-LD, SPDX, richer dependency semantics, etc) to a future metadata 3.0 proposal (or potentially metadata extensions, or 2.x format updates).
I think PEP 426 is actually orthogonal to these proposals. AFAICT, the only reason Robert's PEP as written requires PEP 426 is that he needs a standard serializable format to list dependencies... but he actually defines such a format about 10 lines above for the static bootstrap-requirements key, i.e. a list of specifier strings. So it actually makes more sense to use that for dynamic requirements too for internal consistency, and leave PEP 426 out of it.
pip requires: - distribution name - install_requires [+extras]
today. It will want external dependencies in future (and in the spec I put forward build dependencies would be obtained earlier so could be skipped).
I'd rather not invent a *new* format for handling both of these, but i'm ok if Donald and Nick specifically are.
They're probably a good candidate for the version specifier and environment marker treatment: extracting a "dependency specifier" PEP to give us a building block we can use in the higher level specs. Cheers, Nick.
-Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Nathaniel Smith
-
Nick Coghlan
-
Robert Collins