librelist archives

« back to archive

pep 425/426/427 status

pep 425/426/427 status

From:
Marcus Smith
Date:
2012-12-03 @ 17:47
Daniel:
do you mind summarizing where you think pep 425/426/427 are at right now?
Marcus

Re: [wheel] pep 425/426/427 status

From:
Daniel Holth
Date:
2012-12-03 @ 19:27
It's hard to say where the PEPs are at exactly. The process is ambiguous
and it involves whomever shows up.

PEP 426 (Metadata 1.3) is very far along. Most of the comments and rewrites
have been about things that are unchanged from older versions of the PEP,
not the features I am adding. The latest discussion was about clarifying
the meaning of  Provides-Dist, Obsoletes[-Dist]: and friends.

PEP 425 has been pretty quiet. I think it is probably acceptable. May need
to clarify the filename escaping rules especially - to _ folding. The same
hyphen to underscore folding applies to wheel filenames and should probably
be mentioned in PEP 427.

PEP 427 lost the controversial Ed25519 algorithm and has a clearer
attached-signatures specification with no specified algorithms. I feel the
rest of the document could be more clearly written but it does the job and
has garnered few complaints. It could be that the crypto bits simply
distracted everyone from everything else.


On Mon, Dec 3, 2012 at 12:47 PM, Marcus Smith <qwcode@gmail.com> wrote:

> Daniel:
> do you mind summarizing where you think pep 425/426/427 are at right now?
> Marcus
>

Re: [wheel] pep 425/426/427 status

From:
Paul Moore
Date:
2012-12-03 @ 19:59
On 3 December 2012 19:27, Daniel Holth <dholth@gmail.com> wrote:
> It's hard to say where the PEPs are at exactly. The process is ambiguous and
> it involves whomever shows up.
>
> PEP 426 (Metadata 1.3) is very far along. Most of the comments and rewrites
> have been about things that are unchanged from older versions of the PEP,
> not the features I am adding. The latest discussion was about clarifying the
> meaning of  Provides-Dist, Obsoletes[-Dist]: and friends.
>
> PEP 425 has been pretty quiet. I think it is probably acceptable. May need
> to clarify the filename escaping rules especially - to _ folding. The same
> hyphen to underscore folding applies to wheel filenames and should probably
> be mentioned in PEP 427.
>
> PEP 427 lost the controversial Ed25519 algorithm and has a clearer
> attached-signatures specification with no specified algorithms. I feel the
> rest of the document could be more clearly written but it does the job and
> has garnered few complaints. It could be that the crypto bits simply
> distracted everyone from everything else.

I'd recently been wondering the same thing as Marcus. It's been a bit
quiet on the wheel front for a while. Thanks for the update.

Maybe it's time to pick one and ask for a PEP czar to take the reins
and pronounce. (I'd do them one at the time, trying to push all 3
forward at once tends to confuse the discussion and link them more
than necessary in people's minds). IIRC, Nick Coghlan indicated he
might be willing to do this.

Following on from Marcus' question, what's next if the 3 PEPs get
accepted? Will anything particular happen as a result of acceptance?
In particular, what do the 2 wheel PEPs (427 specifically, and 425 to
the extent that only wheels use the tag format at the moment) mean for
wheels as a standard format? *Can* they make any difference without a
bdist_wheel command in the stdlib? I'm a little concerned that what
seems like consensus is actually largely apathy, because no-one
expects anything to change as a result of the PEPs...

Pessimistically y'rs...
Paul.

Re: [wheel] pep 425/426/427 status

From:
Daniel Holth
Date:
2012-12-03 @ 20:02
On Mon, Dec 3, 2012 at 2:59 PM, Paul Moore <p.f.moore@gmail.com> wrote:

> On 3 December 2012 19:27, Daniel Holth <dholth@gmail.com> wrote:
> > It's hard to say where the PEPs are at exactly. The process is ambiguous
> and
> > it involves whomever shows up.
> >
> > PEP 426 (Metadata 1.3) is very far along. Most of the comments and
> rewrites
> > have been about things that are unchanged from older versions of the PEP,
> > not the features I am adding. The latest discussion was about clarifying
> the
> > meaning of  Provides-Dist, Obsoletes[-Dist]: and friends.
> >
> > PEP 425 has been pretty quiet. I think it is probably acceptable. May
> need
> > to clarify the filename escaping rules especially - to _ folding. The
> same
> > hyphen to underscore folding applies to wheel filenames and should
> probably
> > be mentioned in PEP 427.
> >
> > PEP 427 lost the controversial Ed25519 algorithm and has a clearer
> > attached-signatures specification with no specified algorithms. I feel
> the
> > rest of the document could be more clearly written but it does the job
> and
> > has garnered few complaints. It could be that the crypto bits simply
> > distracted everyone from everything else.
>
> I'd recently been wondering the same thing as Marcus. It's been a bit
> quiet on the wheel front for a while. Thanks for the update.
>
> Maybe it's time to pick one and ask for a PEP czar to take the reins
> and pronounce. (I'd do them one at the time, trying to push all 3
> forward at once tends to confuse the discussion and link them more
> than necessary in people's minds). IIRC, Nick Coghlan indicated he
> might be willing to do this.
>
> Following on from Marcus' question, what's next if the 3 PEPs get
> accepted? Will anything particular happen as a result of acceptance?
> In particular, what do the 2 wheel PEPs (427 specifically, and 425 to
> the extent that only wheels use the tag format at the moment) mean for
> wheels as a standard format? *Can* they make any difference without a
> bdist_wheel command in the stdlib? I'm a little concerned that what
> seems like consensus is actually largely apathy, because no-one
> expects anything to change as a result of the PEPs...
>
> Pessimistically y'rs...
> Paul.
>

The pip maintainers predicate the inclusion of "pip wheel" on the PEPs. Get
the PEPs accepted -> wheel support in pip trunk.

Re: [wheel] pep 425/426/427 status

From:
Marcus Smith
Date:
2012-12-03 @ 20:16
> bdist_wheel command in the stdlib? I'm a little concerned that what
>> seems like consensus is actually largely apathy, because no-one
>> expects anything to change as a result of the PEPs...
>>
>>

> The pip maintainers predicate the inclusion of "pip wheel" on the PEPs.
> Get the PEPs accepted -> wheel support in pip trunk.
>


my idea was that a "positive response" to the PEPs would make a pip merge
more likely.  what that response amounted to, I wasn't sure.
I was kinda waiting for that response, and was steadily trying to improve
the pip fork, and then would bring it up again.
I can't "hans solo" the merge again, so I think 3 maintainer votes would be
needed, if that's possible.

Marcus

Re: [wheel] pep 425/426/427 status

From:
Daniel Holth
Date:
2012-12-03 @ 20:21
On Mon, Dec 3, 2012 at 3:16 PM, Marcus Smith <qwcode@gmail.com> wrote:

>
> bdist_wheel command in the stdlib? I'm a little concerned that what
>>> seems like consensus is actually largely apathy, because no-one
>>> expects anything to change as a result of the PEPs...
>>>
>>>
>
>> The pip maintainers predicate the inclusion of "pip wheel" on the PEPs.
>> Get the PEPs accepted -> wheel support in pip trunk.
>>
>
>
> my idea was that a "positive response" to the PEPs would make a pip merge
> more likely.  what that response amounted to, I wasn't sure.
> I was kinda waiting for that response, and was steadily trying to improve
> the pip fork, and then would bring it up again.
> I can't "hans solo" the merge again, so I think 3 maintainer votes would
> be needed, if that's possible.
>
> Marcus
>

Simultaneously turning the keys on the merge control panel?

Re: [wheel] pep 425/426/427 status

From:
Marcus Smith
Date:
2012-12-03 @ 20:24
what? I can't tell if your question was serious, but I mean getting 3
maintainers to agree to merge the pull.

On Mon, Dec 3, 2012 at 12:21 PM, Daniel Holth <dholth@gmail.com> wrote:

> On Mon, Dec 3, 2012 at 3:16 PM, Marcus Smith <qwcode@gmail.com> wrote:
>
>>
>> bdist_wheel command in the stdlib? I'm a little concerned that what
>>>> seems like consensus is actually largely apathy, because no-one
>>>> expects anything to change as a result of the PEPs...
>>>>
>>>>
>>
>>> The pip maintainers predicate the inclusion of "pip wheel" on the PEPs.
>>> Get the PEPs accepted -> wheel support in pip trunk.
>>>
>>
>>
>> my idea was that a "positive response" to the PEPs would make a pip merge
>> more likely.  what that response amounted to, I wasn't sure.
>> I was kinda waiting for that response, and was steadily trying to improve
>> the pip fork, and then would bring it up again.
>> I can't "hans solo" the merge again, so I think 3 maintainer votes would
>> be needed, if that's possible.
>>
>> Marcus
>>
>
> Simultaneously turning the keys on the merge control panel?
>
>

Re: [wheel] pep 425/426/427 status

From:
Conrado Buhrer
Date:
2012-12-08 @ 14:42
i believe the feature is good to include art in projects.


On Mon, Dec 3, 2012 at 12:24 PM, Marcus Smith <qwcode@gmail.com> wrote:

> what? I can't tell if your question was serious, but I mean getting 3
> maintainers to agree to merge the pull.
>
> On Mon, Dec 3, 2012 at 12:21 PM, Daniel Holth <dholth@gmail.com> wrote:
>
>> On Mon, Dec 3, 2012 at 3:16 PM, Marcus Smith <qwcode@gmail.com> wrote:
>>
>>>
>>> bdist_wheel command in the stdlib? I'm a little concerned that what
>>>>> seems like consensus is actually largely apathy, because no-one
>>>>> expects anything to change as a result of the PEPs...
>>>>>
>>>>>
>>>
>>>> The pip maintainers predicate the inclusion of "pip wheel" on the PEPs.
>>>> Get the PEPs accepted -> wheel support in pip trunk.
>>>>
>>>
>>>
>>> my idea was that a "positive response" to the PEPs would make a pip
>>> merge more likely.  what that response amounted to, I wasn't sure.
>>> I was kinda waiting for that response, and was steadily trying to
>>> improve the pip fork, and then would bring it up again.
>>> I can't "hans solo" the merge again, so I think 3 maintainer votes would
>>> be needed, if that's possible.
>>>
>>> Marcus
>>>
>>
>> Simultaneously turning the keys on the merge control panel?
>>
>>
>

Re: [wheel] pep 425/426/427 status

From:
Daniel Holth
Date:
2012-12-08 @ 15:22
Speaking of art, we still need an official cheese wheel logo/image for the
project.
On Dec 8, 2012 9:42 AM, "Conrado Buhrer" <conrado@buhrer.net> wrote:

> i believe the feature is good to include art in projects.
>
>
> On Mon, Dec 3, 2012 at 12:24 PM, Marcus Smith <qwcode@gmail.com> wrote:
>
>> what? I can't tell if your question was serious, but I mean getting 3
>> maintainers to agree to merge the pull.
>>
>> On Mon, Dec 3, 2012 at 12:21 PM, Daniel Holth <dholth@gmail.com> wrote:
>>
>>> On Mon, Dec 3, 2012 at 3:16 PM, Marcus Smith <qwcode@gmail.com> wrote:
>>>
>>>>
>>>> bdist_wheel command in the stdlib? I'm a little concerned that what
>>>>>> seems like consensus is actually largely apathy, because no-one
>>>>>> expects anything to change as a result of the PEPs...
>>>>>>
>>>>>>
>>>>
>>>>> The pip maintainers predicate the inclusion of "pip wheel" on the
>>>>> PEPs. Get the PEPs accepted -> wheel support in pip trunk.
>>>>>
>>>>
>>>>
>>>> my idea was that a "positive response" to the PEPs would make a pip
>>>> merge more likely.  what that response amounted to, I wasn't sure.
>>>> I was kinda waiting for that response, and was steadily trying to
>>>> improve the pip fork, and then would bring it up again.
>>>> I can't "hans solo" the merge again, so I think 3 maintainer votes
>>>> would be needed, if that's possible.
>>>>
>>>> Marcus
>>>>
>>>
>>> Simultaneously turning the keys on the merge control panel?
>>>
>>>
>>
>

Re: [wheel] pep 425/426/427 status

From:
Conrado Buhrer
Date:
2012-12-08 @ 19:33
Start a competition :D


On Sat, Dec 8, 2012 at 7:22 AM, Daniel Holth <dholth@gmail.com> wrote:

> Speaking of art, we still need an official cheese wheel logo/image for the
> project.
> On Dec 8, 2012 9:42 AM, "Conrado Buhrer" <conrado@buhrer.net> wrote:
>
>> i believe the feature is good to include art in projects.
>>
>>
>> On Mon, Dec 3, 2012 at 12:24 PM, Marcus Smith <qwcode@gmail.com> wrote:
>>
>>> what? I can't tell if your question was serious, but I mean getting 3
>>> maintainers to agree to merge the pull.
>>>
>>> On Mon, Dec 3, 2012 at 12:21 PM, Daniel Holth <dholth@gmail.com> wrote:
>>>
>>>> On Mon, Dec 3, 2012 at 3:16 PM, Marcus Smith <qwcode@gmail.com> wrote:
>>>>
>>>>>
>>>>> bdist_wheel command in the stdlib? I'm a little concerned that what
>>>>>>> seems like consensus is actually largely apathy, because no-one
>>>>>>> expects anything to change as a result of the PEPs...
>>>>>>>
>>>>>>>
>>>>>
>>>>>> The pip maintainers predicate the inclusion of "pip wheel" on the
>>>>>> PEPs. Get the PEPs accepted -> wheel support in pip trunk.
>>>>>>
>>>>>
>>>>>
>>>>> my idea was that a "positive response" to the PEPs would make a pip
>>>>> merge more likely.  what that response amounted to, I wasn't sure.
>>>>> I was kinda waiting for that response, and was steadily trying to
>>>>> improve the pip fork, and then would bring it up again.
>>>>> I can't "hans solo" the merge again, so I think 3 maintainer votes
>>>>> would be needed, if that's possible.
>>>>>
>>>>> Marcus
>>>>>
>>>>
>>>> Simultaneously turning the keys on the merge control panel?
>>>>
>>>>
>>>
>>