On Monday, December 11, 2017, Dustin Ingram wrote:
> After working a bit on an implementation of the "JSON-compatible
> Metadata" section in this PEP, I'm noticing that it might be more
> useful if it had the following step instead for canonicalizing the
> field names:
>
> > #. All transformed ke
After working a bit on an implementation of the "JSON-compatible
Metadata" section in this PEP, I'm noticing that it might be more
useful if it had the following step instead for canonicalizing the
field names:
> #. All transformed keys should be reduced to lower case. Hyphens should be
>repla
I don't know why the parentheses were included in the older pep. They are
widely deployed. We probably can get rid of them or make them optional in a
practical parser.
On Sat, Dec 9, 2017, 02:03 Nick Coghlan wrote:
> On 9 December 2017 at 02:42, Thomas Kluyver wrote:
> > Dustin asked me to brin
On 9 December 2017 at 02:42, Thomas Kluyver wrote:
> Dustin asked me to bring this issue to this thread:
>
> Metadata version 1.2 (PEP 345) says that version specifiers within a
> Requires-Dist field should go in parentheses: "zope.interface (>3.5.0)".
> The metadata spec on PyPUG repeats this.
>
Dustin asked me to bring this issue to this thread:
Metadata version 1.2 (PEP 345) says that version specifiers within a
Requires-Dist field should go in parentheses: "zope.interface (>3.5.0)".
The metadata spec on PyPUG repeats this.
However, PEP 508 says that the parentheses are not needed, and
>From "[distutils] Multiple package authors" [1]
- How should multiple author-email and maintainer-email addresses be
specified?
- Should we add security-email and/or security-disclosure-instructions?
[1] http://markmail.org/thread/xmwfktnsbmpakv6b
On Wednesday, December 6, 2017, Nick Coghlan
On 6 December 2017 at 02:39, Dustin Ingram wrote:
> Hi all,
>
> I'd appreciate your feedback on the following Metadata 1.3 PEP.
>
> The goal here is not to provide a full specification for all fields as
> in previous PEPs, but to:
>
> * Motivate and describe the addition of the new fields or chang
On 6 December 2017 at 07:02, Nathaniel Smith wrote:
> On Dec 5, 2017 08:42, "Dustin Ingram" wrote:
>
>
> Provides-Extra (optional, multiple use)
> :::
>
> A string containing the name of an optional feature. Must be a valid Python
> identifier. May be used to m
> On Dec 5, 2017, at 4:02 PM, Nathaniel Smith wrote:
>
> I haven't followed this so sorry if this is an annoying comment, but having
> read this description I still don't really understand what Provides-Extra is
> doing. Don't packages already include extra information? What problem
> motiva
On 5 December 2017 at 20:34, Dustin Ingram wrote:
> Ah, I see, by "other two" I thought you meant the other two new fields.
>
> Looking at https://www.python.org/dev/peps/pep-0566/ might make it
> more clear that I originally intended the "New in Version 1.3" and
> "Changed in Version 1.3" heading
On Dec 5, 2017 08:42, "Dustin Ingram" wrote:
Provides-Extra (optional, multiple use)
:::
A string containing the name of an optional feature. Must be a valid Python
identifier. May be used to make a dependency conditional on whether the
optional feature has b
Ah, I see, by "other two" I thought you meant the other two new fields.
Looking at https://www.python.org/dev/peps/pep-0566/ might make it
more clear that I originally intended the "New in Version 1.3" and
"Changed in Version 1.3" headings to only be under the "Fields"
heading, so the outline woul
On 5 December 2017 at 18:11, Dustin Ingram wrote:
>> I was a bit confused at first by the fact that you describe
>> environment markers but not where they are allowed. On checking, I
>> find that this is defined in version 1.2 (PEP 345). It might be worth
>> a small clarification that this (and na
> I was a bit confused at first by the fact that you describe
> environment markers but not where they are allowed. On checking, I
> find that this is defined in version 1.2 (PEP 345). It might be worth
> a small clarification that this (and name and version specifiers) are
> still used in the same
LGTM.
I was a bit confused at first by the fact that you describe
environment markers but not where they are allowed. On checking, I
find that this is defined in version 1.2 (PEP 345). It might be worth
a small clarification that this (and name and version specifiers) are
still used in the same wa
On 12/05/2017 11:39 AM, Dustin Ingram wrote:
> Hi all,
>
> I'd appreciate your feedback on the following Metadata 1.3 PEP.
>
> The goal here is not to provide a full specification for all fields as
> in previous PEPs, but to:
>
> * Motivate and describe the addition of the new fields or changes
Hi all,
I'd appreciate your feedback on the following Metadata 1.3 PEP.
The goal here is not to provide a full specification for all fields as
in previous PEPs, but to:
* Motivate and describe the addition of the new fields or changes to
existing fields;
* Point to the Core Metadata Specificatio
17 matches
Mail list logo
