Re: [Distutils] pythonhosted.org doc upload no longer works

[Noah Kantrowitz]

This was discussed several years ago in 
https://mail.python.org/pipermail/distutils-sig/2015-May/026381.html and a few 
other threads. The final phases went out earlier this year. I don't think there 
is any plan to re-enable uploads to pythonhosted at this time. If you want a 
one-off redirect change or just having the old files removed, we can probably 
do that though, but I very much defer to Donald and others on that :)

--Noah

> On Sep 4, 2017, at 9:43 PM, Giampaolo Rodola'  wrote:
> 
> I think it's wise to revert that commit. It seems pythonhosted only suggested 
> to migrate to RTD but there never was an official shutdown date or warning 
> (either via direct email or message on the web page). 
> 
> On Tue, Sep 5, 2017 at 12:19 PM, Berker Peksağ  
> wrote:
> On Mon, Sep 4, 2017 at 4:56 PM, Nick Coghlan  wrote:
> > On 2 September 2017 at 15:34, Giampaolo Rodola'  wrote:
> >> I know it was deprecated long ago in favor of readthedocs but I kept
> >> postponing it and my doc is still hosted on
> >> https://pythonhosted.org/psutil/.
> >
> > While we've talked about deprecating it, it *hasn't* been deprecated.
> > Looking at https://github.com/pypa/pypi-legacy/commits/production, I'm
> > not seeing anything obvious that would have caused problems with docs
> > management, but that's probably still the best issue tracker to use to
> > report the bug.
> 
> See the 'doc_upload' handler at
> https://github.com/pypa/pypi-legacy/commit/1598e6ea0f7fb0393891f6c6bcbf84c191834a0e#diff-19fadc30e1b17100568adbd8c6c3cc13R2804
> I've collected all information I found at
> https://github.com/pypa/pypi-legacy/issues/672#issuecomment-316125918
> Please correct me if I missed anything.
> 
> --Berker
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
> 
> 
> 
> -- 
> Giampaolo - http://grodola.blogspot.com
> 
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonhosted.org doc upload no longer works

[Giampaolo Rodola']

I think it's wise to revert that commit. It seems pythonhosted only
suggested to migrate to RTD but there never was an official shutdown date
or warning (either via direct email or message on the web page).

On Tue, Sep 5, 2017 at 12:19 PM, Berker Peksağ 
wrote:

> On Mon, Sep 4, 2017 at 4:56 PM, Nick Coghlan  wrote:
> > On 2 September 2017 at 15:34, Giampaolo Rodola' 
> wrote:
> >> I know it was deprecated long ago in favor of readthedocs but I kept
> >> postponing it and my doc is still hosted on
> >> https://pythonhosted.org/psutil/.
> >
> > While we've talked about deprecating it, it *hasn't* been deprecated.
> > Looking at https://github.com/pypa/pypi-legacy/commits/production, I'm
> > not seeing anything obvious that would have caused problems with docs
> > management, but that's probably still the best issue tracker to use to
> > report the bug.
>
> See the 'doc_upload' handler at
> https://github.com/pypa/pypi-legacy/commit/1598e6ea0f7fb0393891f6c6bcbf84
> c191834a0e#diff-19fadc30e1b17100568adbd8c6c3cc13R2804
> I've collected all information I found at
> https://github.com/pypa/pypi-legacy/issues/672#issuecomment-316125918
> Please correct me if I missed anything.
>
> --Berker
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Giampaolo - http://grodola.blogspot.com
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonhosted.org doc upload no longer works

[Berker Peksağ]

On Mon, Sep 4, 2017 at 4:56 PM, Nick Coghlan  wrote:
> On 2 September 2017 at 15:34, Giampaolo Rodola'  wrote:
>> I know it was deprecated long ago in favor of readthedocs but I kept
>> postponing it and my doc is still hosted on
>> https://pythonhosted.org/psutil/.
>
> While we've talked about deprecating it, it *hasn't* been deprecated.
> Looking at https://github.com/pypa/pypi-legacy/commits/production, I'm
> not seeing anything obvious that would have caused problems with docs
> management, but that's probably still the best issue tracker to use to
> report the bug.

See the 'doc_upload' handler at
https://github.com/pypa/pypi-legacy/commit/1598e6ea0f7fb0393891f6c6bcbf84c191834a0e#diff-19fadc30e1b17100568adbd8c6c3cc13R2804
I've collected all information I found at
https://github.com/pypa/pypi-legacy/issues/672#issuecomment-316125918
Please correct me if I missed anything.

--Berker
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonhosted.org doc upload no longer works

[Giampaolo Rodola']

Thanks a lot Nick. I filed a bug:
https://github.com/pypa/pypi-legacy/issues/700

On Mon, Sep 4, 2017 at 9:56 PM, Nick Coghlan  wrote:

> On 2 September 2017 at 15:34, Giampaolo Rodola' 
> wrote:
> > I know it was deprecated long ago in favor of readthedocs but I kept
> > postponing it and my doc is still hosted on
> > https://pythonhosted.org/psutil/.
>
> While we've talked about deprecating it, it *hasn't* been deprecated.
> Looking at https://github.com/pypa/pypi-legacy/commits/production, I'm
> not seeing anything obvious that would have caused problems with docs
> management, but that's probably still the best issue tracker to use to
> report the bug.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>



-- 
Giampaolo - http://grodola.blogspot.com
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[xoviat]

Supposedly there is some meeting tomorrow concerning the wheel project that
will determine the fate of dist_info. So that is why I bought it up.

On Sep 4, 2017 9:00 PM, "Chris Jerdonek"  wrote:

> On Mon, Sep 4, 2017 at 6:41 PM, xoviat  wrote:
> > The PR that I am taking about is not for pip but for the wheel project.
>
> Okay, well you started the thread asking something similar for your
> pip PR (see below). I'm sure similar considerations hold for the wheel
> project.
>
> On Mon, Sep 4, 2017 at 5:11 PM, xoviat  wrote:
> > Also if someone with pip write access could please discuss and hopefully
> > merge my initial PR on pip, I would very much appreciate it. Paul seems
> to
> > be short on time.
>
> --Chris
>
>
> >
> > On Sep 4, 2017 8:19 PM, "Chris Jerdonek" 
> wrote:
> >>
> >> On Mon, Sep 4, 2017 at 6:08 PM, xoviat  wrote:
> >> > In any case, we're going to need this for prepare_metadata, so the
> >> > question
> >> > you should ask is: what are the reasons for *not* merging this? I
> >> > haven't
> >> > heard any so far but that doesn't mean that they don't exist. If there
> >> > are
> >> > none, then I don't see why we cannot merge my wheel PR and do a
> release.
> >>
> >> FYI, you're not the only one waiting for PR's to be merged. There are
> >> 56 other PR's, some of which have already been approved by repo
> >> members with commit access. I would try to be a little more patient.
> >> Otherwise, everyone can be emailing the list saying the same thing and
> >> asking why their PR isn't being merged.
> >>
> >> --Chris
> >>
> >> >
> >> > 2017-09-04 19:51 GMT-05:00 xoviat :
> >> >>
> >> >> > The only reason I can think of that setuptools would need a
> dist_info
> >> >> command would be to implement the PEP 517 prepare_wheel_metadata
> hook.
> >> >>
> >> >> Yes. That is absolutely correct.
> >> >>
> >> >> > But this hook is optional and in fact provides no value right now,
> so
> >> >> it can't be a blocker for anything.
> >> >>
> >> >> The simplest way to start on this issue is to replace egg_info in pip
> >> >> with
> >> >> prepare_metadata_for_build_wheel. It is absolutely a historical
> >> >> artifact but
> >> >> I need to work on one issue at a time. The next issue will be
> replacing
> >> >> egg_info in pip with prepare_metadata_for_build_wheel.
> >> >>
> >> >> 2017-09-04 19:34 GMT-05:00 Nathaniel Smith :
> >> >>>
> >> >>> On Mon, Sep 4, 2017 at 5:09 PM, xoviat  wrote:
> >> >>> > Nathaniel:
> >> >>> >
> >> >>> > Pip requires egg_info to discover dependencies of source
> >> >>> > distributions
> >> >>> > so
> >> >>> > that it can build wheels all at once after downloading the
> >> >>> > requirements. I
> >> >>> > need to move pip off of egg_info as soon as possible and dist_info
> >> >>> > is
> >> >>> > required to do that.
> >> >>>
> >> >>> "Requires" is a strong word -- AFAIK this is just a historical
> >> >>> artifact. I don't really know what you're talking about in the
> second
> >> >>> sentence.
> >> >>>
> >> >>> The only reason I can think of that setuptools would need a
> dist_info
> >> >>> command would be to implement the PEP 517 prepare_wheel_metadata
> hook.
> >> >>> But this hook is optional and in fact provides no value right now,
> so
> >> >>> it can't be a blocker for anything. (In fact I can't see any reason
> >> >>> why pip would ever call it before the resolver lands.) So either (a)
> >> >>> there's some other reason you want a dist_info command, (b) there's
> >> >>> some reason I'm missing why prepare_wheel_metadata matters, or (c)
> one
> >> >>> of us is misunderstanding something :-).
> >> >>>
> >> >>> -n
> >> >>>
> >> >>> > 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
> >> >>> >>
> >> >>> >> On Sun, Sep 3, 2017 at 11:14 AM, xoviat 
> wrote:
> >> >>> >> > Just an update for everyone here:
> >> >>> >> >
> >> >>> >> > 1. We're currently waiting on the implementation of the
> >> >>> >> > 'dist_info"
> >> >>> >> > command
> >> >>> >> > in the wheel project.
> >> >>> >> > 2. Once that is done we can switch pip over to reading
> dist-info
> >> >>> >> > rather
> >> >>> >> > than
> >> >>> >> > egg_info.
> >> >>> >> > 3. Then we can move the backend over to setuptools. Because
> Jacob
> >> >>> >> > has a
> >> >>> >> > much
> >> >>> >> > more efficient release system than pip, I anticipate having a
> >> >>> >> > release of
> >> >>> >> > setuptools first and then we can switch pip over to requiring a
> >> >>> >> > newer
> >> >>> >> > setuptools via PEP 518.
> >> >>> >>
> >> >>> >> I don't think pip actually has any use for the PEP 517
> >> >>> >> prepare_wheel_metadata hook right now though? Historically
> >> >>> >> 'setup.py
> >> >>> >> egg-info' was needed to kluge around unwanted behavior in
> 'setup.py
> >> >>> >> install', but with a PEP 517 backend that's irrelevant because
> >> >>> >> 

Re: [Distutils] PEP 517 again

[Chris Jerdonek]

On Mon, Sep 4, 2017 at 6:41 PM, xoviat  wrote:
> The PR that I am taking about is not for pip but for the wheel project.

Okay, well you started the thread asking something similar for your
pip PR (see below). I'm sure similar considerations hold for the wheel
project.

On Mon, Sep 4, 2017 at 5:11 PM, xoviat  wrote:
> Also if someone with pip write access could please discuss and hopefully
> merge my initial PR on pip, I would very much appreciate it. Paul seems to
> be short on time.

--Chris


>
> On Sep 4, 2017 8:19 PM, "Chris Jerdonek"  wrote:
>>
>> On Mon, Sep 4, 2017 at 6:08 PM, xoviat  wrote:
>> > In any case, we're going to need this for prepare_metadata, so the
>> > question
>> > you should ask is: what are the reasons for *not* merging this? I
>> > haven't
>> > heard any so far but that doesn't mean that they don't exist. If there
>> > are
>> > none, then I don't see why we cannot merge my wheel PR and do a release.
>>
>> FYI, you're not the only one waiting for PR's to be merged. There are
>> 56 other PR's, some of which have already been approved by repo
>> members with commit access. I would try to be a little more patient.
>> Otherwise, everyone can be emailing the list saying the same thing and
>> asking why their PR isn't being merged.
>>
>> --Chris
>>
>> >
>> > 2017-09-04 19:51 GMT-05:00 xoviat :
>> >>
>> >> > The only reason I can think of that setuptools would need a dist_info
>> >> command would be to implement the PEP 517 prepare_wheel_metadata hook.
>> >>
>> >> Yes. That is absolutely correct.
>> >>
>> >> > But this hook is optional and in fact provides no value right now, so
>> >> it can't be a blocker for anything.
>> >>
>> >> The simplest way to start on this issue is to replace egg_info in pip
>> >> with
>> >> prepare_metadata_for_build_wheel. It is absolutely a historical
>> >> artifact but
>> >> I need to work on one issue at a time. The next issue will be replacing
>> >> egg_info in pip with prepare_metadata_for_build_wheel.
>> >>
>> >> 2017-09-04 19:34 GMT-05:00 Nathaniel Smith :
>> >>>
>> >>> On Mon, Sep 4, 2017 at 5:09 PM, xoviat  wrote:
>> >>> > Nathaniel:
>> >>> >
>> >>> > Pip requires egg_info to discover dependencies of source
>> >>> > distributions
>> >>> > so
>> >>> > that it can build wheels all at once after downloading the
>> >>> > requirements. I
>> >>> > need to move pip off of egg_info as soon as possible and dist_info
>> >>> > is
>> >>> > required to do that.
>> >>>
>> >>> "Requires" is a strong word -- AFAIK this is just a historical
>> >>> artifact. I don't really know what you're talking about in the second
>> >>> sentence.
>> >>>
>> >>> The only reason I can think of that setuptools would need a dist_info
>> >>> command would be to implement the PEP 517 prepare_wheel_metadata hook.
>> >>> But this hook is optional and in fact provides no value right now, so
>> >>> it can't be a blocker for anything. (In fact I can't see any reason
>> >>> why pip would ever call it before the resolver lands.) So either (a)
>> >>> there's some other reason you want a dist_info command, (b) there's
>> >>> some reason I'm missing why prepare_wheel_metadata matters, or (c) one
>> >>> of us is misunderstanding something :-).
>> >>>
>> >>> -n
>> >>>
>> >>> > 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
>> >>> >>
>> >>> >> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
>> >>> >> > Just an update for everyone here:
>> >>> >> >
>> >>> >> > 1. We're currently waiting on the implementation of the
>> >>> >> > 'dist_info"
>> >>> >> > command
>> >>> >> > in the wheel project.
>> >>> >> > 2. Once that is done we can switch pip over to reading dist-info
>> >>> >> > rather
>> >>> >> > than
>> >>> >> > egg_info.
>> >>> >> > 3. Then we can move the backend over to setuptools. Because Jacob
>> >>> >> > has a
>> >>> >> > much
>> >>> >> > more efficient release system than pip, I anticipate having a
>> >>> >> > release of
>> >>> >> > setuptools first and then we can switch pip over to requiring a
>> >>> >> > newer
>> >>> >> > setuptools via PEP 518.
>> >>> >>
>> >>> >> I don't think pip actually has any use for the PEP 517
>> >>> >> prepare_wheel_metadata hook right now though? Historically
>> >>> >> 'setup.py
>> >>> >> egg-info' was needed to kluge around unwanted behavior in 'setup.py
>> >>> >> install', but with a PEP 517 backend that's irrelevant because
>> >>> >> 'setup.py install' is never used. And in the future when pip has a
>> >>> >> real resolver, then prepare_wheel_metadata should allow some
>> >>> >> optimizations. But right now, prepare_wheel_metadata is completely
>> >>> >> useless AFAIK.
>> >>> >>
>> >>> >> So why is 'setup.py dist_info' a blocker for things?
>> >>> >>
>> >>> >> -n
>> >>> >>
>> >>> >> --
>> >>> >> Nathaniel J. Smith -- https://vorpus.org
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> 

Re: [Distutils] PEP 517 again

[xoviat]

The PR that I am taking about is not for pip but for the wheel project.

On Sep 4, 2017 8:19 PM, "Chris Jerdonek"  wrote:

> On Mon, Sep 4, 2017 at 6:08 PM, xoviat  wrote:
> > In any case, we're going to need this for prepare_metadata, so the
> question
> > you should ask is: what are the reasons for *not* merging this? I haven't
> > heard any so far but that doesn't mean that they don't exist. If there
> are
> > none, then I don't see why we cannot merge my wheel PR and do a release.
>
> FYI, you're not the only one waiting for PR's to be merged. There are
> 56 other PR's, some of which have already been approved by repo
> members with commit access. I would try to be a little more patient.
> Otherwise, everyone can be emailing the list saying the same thing and
> asking why their PR isn't being merged.
>
> --Chris
>
> >
> > 2017-09-04 19:51 GMT-05:00 xoviat :
> >>
> >> > The only reason I can think of that setuptools would need a dist_info
> >> command would be to implement the PEP 517 prepare_wheel_metadata hook.
> >>
> >> Yes. That is absolutely correct.
> >>
> >> > But this hook is optional and in fact provides no value right now, so
> >> it can't be a blocker for anything.
> >>
> >> The simplest way to start on this issue is to replace egg_info in pip
> with
> >> prepare_metadata_for_build_wheel. It is absolutely a historical
> artifact but
> >> I need to work on one issue at a time. The next issue will be replacing
> >> egg_info in pip with prepare_metadata_for_build_wheel.
> >>
> >> 2017-09-04 19:34 GMT-05:00 Nathaniel Smith :
> >>>
> >>> On Mon, Sep 4, 2017 at 5:09 PM, xoviat  wrote:
> >>> > Nathaniel:
> >>> >
> >>> > Pip requires egg_info to discover dependencies of source
> distributions
> >>> > so
> >>> > that it can build wheels all at once after downloading the
> >>> > requirements. I
> >>> > need to move pip off of egg_info as soon as possible and dist_info is
> >>> > required to do that.
> >>>
> >>> "Requires" is a strong word -- AFAIK this is just a historical
> >>> artifact. I don't really know what you're talking about in the second
> >>> sentence.
> >>>
> >>> The only reason I can think of that setuptools would need a dist_info
> >>> command would be to implement the PEP 517 prepare_wheel_metadata hook.
> >>> But this hook is optional and in fact provides no value right now, so
> >>> it can't be a blocker for anything. (In fact I can't see any reason
> >>> why pip would ever call it before the resolver lands.) So either (a)
> >>> there's some other reason you want a dist_info command, (b) there's
> >>> some reason I'm missing why prepare_wheel_metadata matters, or (c) one
> >>> of us is misunderstanding something :-).
> >>>
> >>> -n
> >>>
> >>> > 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
> >>> >>
> >>> >> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
> >>> >> > Just an update for everyone here:
> >>> >> >
> >>> >> > 1. We're currently waiting on the implementation of the
> 'dist_info"
> >>> >> > command
> >>> >> > in the wheel project.
> >>> >> > 2. Once that is done we can switch pip over to reading dist-info
> >>> >> > rather
> >>> >> > than
> >>> >> > egg_info.
> >>> >> > 3. Then we can move the backend over to setuptools. Because Jacob
> >>> >> > has a
> >>> >> > much
> >>> >> > more efficient release system than pip, I anticipate having a
> >>> >> > release of
> >>> >> > setuptools first and then we can switch pip over to requiring a
> >>> >> > newer
> >>> >> > setuptools via PEP 518.
> >>> >>
> >>> >> I don't think pip actually has any use for the PEP 517
> >>> >> prepare_wheel_metadata hook right now though? Historically 'setup.py
> >>> >> egg-info' was needed to kluge around unwanted behavior in 'setup.py
> >>> >> install', but with a PEP 517 backend that's irrelevant because
> >>> >> 'setup.py install' is never used. And in the future when pip has a
> >>> >> real resolver, then prepare_wheel_metadata should allow some
> >>> >> optimizations. But right now, prepare_wheel_metadata is completely
> >>> >> useless AFAIK.
> >>> >>
> >>> >> So why is 'setup.py dist_info' a blocker for things?
> >>> >>
> >>> >> -n
> >>> >>
> >>> >> --
> >>> >> Nathaniel J. Smith -- https://vorpus.org
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Nathaniel J. Smith -- https://vorpus.org
> >>
> >>
> >
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[Chris Jerdonek]

On Mon, Sep 4, 2017 at 6:08 PM, xoviat  wrote:
> In any case, we're going to need this for prepare_metadata, so the question
> you should ask is: what are the reasons for *not* merging this? I haven't
> heard any so far but that doesn't mean that they don't exist. If there are
> none, then I don't see why we cannot merge my wheel PR and do a release.

FYI, you're not the only one waiting for PR's to be merged. There are
56 other PR's, some of which have already been approved by repo
members with commit access. I would try to be a little more patient.
Otherwise, everyone can be emailing the list saying the same thing and
asking why their PR isn't being merged.

--Chris

>
> 2017-09-04 19:51 GMT-05:00 xoviat :
>>
>> > The only reason I can think of that setuptools would need a dist_info
>> command would be to implement the PEP 517 prepare_wheel_metadata hook.
>>
>> Yes. That is absolutely correct.
>>
>> > But this hook is optional and in fact provides no value right now, so
>> it can't be a blocker for anything.
>>
>> The simplest way to start on this issue is to replace egg_info in pip with
>> prepare_metadata_for_build_wheel. It is absolutely a historical artifact but
>> I need to work on one issue at a time. The next issue will be replacing
>> egg_info in pip with prepare_metadata_for_build_wheel.
>>
>> 2017-09-04 19:34 GMT-05:00 Nathaniel Smith :
>>>
>>> On Mon, Sep 4, 2017 at 5:09 PM, xoviat  wrote:
>>> > Nathaniel:
>>> >
>>> > Pip requires egg_info to discover dependencies of source distributions
>>> > so
>>> > that it can build wheels all at once after downloading the
>>> > requirements. I
>>> > need to move pip off of egg_info as soon as possible and dist_info is
>>> > required to do that.
>>>
>>> "Requires" is a strong word -- AFAIK this is just a historical
>>> artifact. I don't really know what you're talking about in the second
>>> sentence.
>>>
>>> The only reason I can think of that setuptools would need a dist_info
>>> command would be to implement the PEP 517 prepare_wheel_metadata hook.
>>> But this hook is optional and in fact provides no value right now, so
>>> it can't be a blocker for anything. (In fact I can't see any reason
>>> why pip would ever call it before the resolver lands.) So either (a)
>>> there's some other reason you want a dist_info command, (b) there's
>>> some reason I'm missing why prepare_wheel_metadata matters, or (c) one
>>> of us is misunderstanding something :-).
>>>
>>> -n
>>>
>>> > 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
>>> >>
>>> >> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
>>> >> > Just an update for everyone here:
>>> >> >
>>> >> > 1. We're currently waiting on the implementation of the 'dist_info"
>>> >> > command
>>> >> > in the wheel project.
>>> >> > 2. Once that is done we can switch pip over to reading dist-info
>>> >> > rather
>>> >> > than
>>> >> > egg_info.
>>> >> > 3. Then we can move the backend over to setuptools. Because Jacob
>>> >> > has a
>>> >> > much
>>> >> > more efficient release system than pip, I anticipate having a
>>> >> > release of
>>> >> > setuptools first and then we can switch pip over to requiring a
>>> >> > newer
>>> >> > setuptools via PEP 518.
>>> >>
>>> >> I don't think pip actually has any use for the PEP 517
>>> >> prepare_wheel_metadata hook right now though? Historically 'setup.py
>>> >> egg-info' was needed to kluge around unwanted behavior in 'setup.py
>>> >> install', but with a PEP 517 backend that's irrelevant because
>>> >> 'setup.py install' is never used. And in the future when pip has a
>>> >> real resolver, then prepare_wheel_metadata should allow some
>>> >> optimizations. But right now, prepare_wheel_metadata is completely
>>> >> useless AFAIK.
>>> >>
>>> >> So why is 'setup.py dist_info' a blocker for things?
>>> >>
>>> >> -n
>>> >>
>>> >> --
>>> >> Nathaniel J. Smith -- https://vorpus.org
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Nathaniel J. Smith -- https://vorpus.org
>>
>>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[Nathaniel Smith]

On Mon, Sep 4, 2017 at 5:51 PM, xoviat  wrote:
>> The only reason I can think of that setuptools would need a dist_info
> command would be to implement the PEP 517 prepare_wheel_metadata hook.
>
> Yes. That is absolutely correct.
>
>> But this hook is optional and in fact provides no value right now, so
> it can't be a blocker for anything.
>
> The simplest way to start on this issue is to replace egg_info in pip with
> prepare_metadata_for_build_wheel. It is absolutely a historical artifact but
> I need to work on one issue at a time. The next issue will be replacing
> egg_info in pip with prepare_metadata_for_build_wheel.

This still doesn't make sense to me.

To support PEP 517, pip HAS to support backends that don't provide
prepare_metadata_for_build_wheel. You will have to handle this before
PEP 517 support can ship. So what's your plan for after you replace
egg_info with prepare_metadata_for_build_wheel? Turning around and
deleting the code you just wrote?

-n

> 2017-09-04 19:34 GMT-05:00 Nathaniel Smith :
>>
>> On Mon, Sep 4, 2017 at 5:09 PM, xoviat  wrote:
>> > Nathaniel:
>> >
>> > Pip requires egg_info to discover dependencies of source distributions
>> > so
>> > that it can build wheels all at once after downloading the requirements.
>> > I
>> > need to move pip off of egg_info as soon as possible and dist_info is
>> > required to do that.
>>
>> "Requires" is a strong word -- AFAIK this is just a historical
>> artifact. I don't really know what you're talking about in the second
>> sentence.
>>
>> The only reason I can think of that setuptools would need a dist_info
>> command would be to implement the PEP 517 prepare_wheel_metadata hook.
>> But this hook is optional and in fact provides no value right now, so
>> it can't be a blocker for anything. (In fact I can't see any reason
>> why pip would ever call it before the resolver lands.) So either (a)
>> there's some other reason you want a dist_info command, (b) there's
>> some reason I'm missing why prepare_wheel_metadata matters, or (c) one
>> of us is misunderstanding something :-).
>>
>> -n
>>
>> > 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
>> >>
>> >> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
>> >> > Just an update for everyone here:
>> >> >
>> >> > 1. We're currently waiting on the implementation of the 'dist_info"
>> >> > command
>> >> > in the wheel project.
>> >> > 2. Once that is done we can switch pip over to reading dist-info
>> >> > rather
>> >> > than
>> >> > egg_info.
>> >> > 3. Then we can move the backend over to setuptools. Because Jacob has
>> >> > a
>> >> > much
>> >> > more efficient release system than pip, I anticipate having a release
>> >> > of
>> >> > setuptools first and then we can switch pip over to requiring a newer
>> >> > setuptools via PEP 518.
>> >>
>> >> I don't think pip actually has any use for the PEP 517
>> >> prepare_wheel_metadata hook right now though? Historically 'setup.py
>> >> egg-info' was needed to kluge around unwanted behavior in 'setup.py
>> >> install', but with a PEP 517 backend that's irrelevant because
>> >> 'setup.py install' is never used. And in the future when pip has a
>> >> real resolver, then prepare_wheel_metadata should allow some
>> >> optimizations. But right now, prepare_wheel_metadata is completely
>> >> useless AFAIK.
>> >>
>> >> So why is 'setup.py dist_info' a blocker for things?
>> >>
>> >> -n
>> >>
>> >> --
>> >> Nathaniel J. Smith -- https://vorpus.org
>> >
>> >
>>
>>
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>
>



-- 
Nathaniel J. Smith -- https://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[xoviat]

In any case, we're going to need this for prepare_metadata, so the question
you should ask is: what are the reasons for *not* merging this? I haven't
heard any so far but that doesn't mean that they don't exist. If there are
none, then I don't see why we cannot merge my wheel PR and do a release.

2017-09-04 19:51 GMT-05:00 xoviat :

> > The only reason I can think of that setuptools would need a dist_info
> command would be to implement the PEP 517 prepare_wheel_metadata hook.
>
> Yes. That is absolutely correct.
>
> > But this hook is optional and in fact provides no value right now, so
> it can't be a blocker for anything.
>
> The simplest way to start on this issue is to replace egg_info in pip with
> prepare_metadata_for_build_wheel. It is absolutely a historical artifact
> but I need to work on one issue at a time. The next issue will be replacing
> egg_info in pip with prepare_metadata_for_build_wheel.
>
> 2017-09-04 19:34 GMT-05:00 Nathaniel Smith :
>
>> On Mon, Sep 4, 2017 at 5:09 PM, xoviat  wrote:
>> > Nathaniel:
>> >
>> > Pip requires egg_info to discover dependencies of source distributions
>> so
>> > that it can build wheels all at once after downloading the
>> requirements. I
>> > need to move pip off of egg_info as soon as possible and dist_info is
>> > required to do that.
>>
>> "Requires" is a strong word -- AFAIK this is just a historical
>> artifact. I don't really know what you're talking about in the second
>> sentence.
>>
>> The only reason I can think of that setuptools would need a dist_info
>> command would be to implement the PEP 517 prepare_wheel_metadata hook.
>> But this hook is optional and in fact provides no value right now, so
>> it can't be a blocker for anything. (In fact I can't see any reason
>> why pip would ever call it before the resolver lands.) So either (a)
>> there's some other reason you want a dist_info command, (b) there's
>> some reason I'm missing why prepare_wheel_metadata matters, or (c) one
>> of us is misunderstanding something :-).
>>
>> -n
>>
>> > 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
>> >>
>> >> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
>> >> > Just an update for everyone here:
>> >> >
>> >> > 1. We're currently waiting on the implementation of the 'dist_info"
>> >> > command
>> >> > in the wheel project.
>> >> > 2. Once that is done we can switch pip over to reading dist-info
>> rather
>> >> > than
>> >> > egg_info.
>> >> > 3. Then we can move the backend over to setuptools. Because Jacob
>> has a
>> >> > much
>> >> > more efficient release system than pip, I anticipate having a
>> release of
>> >> > setuptools first and then we can switch pip over to requiring a newer
>> >> > setuptools via PEP 518.
>> >>
>> >> I don't think pip actually has any use for the PEP 517
>> >> prepare_wheel_metadata hook right now though? Historically 'setup.py
>> >> egg-info' was needed to kluge around unwanted behavior in 'setup.py
>> >> install', but with a PEP 517 backend that's irrelevant because
>> >> 'setup.py install' is never used. And in the future when pip has a
>> >> real resolver, then prepare_wheel_metadata should allow some
>> >> optimizations. But right now, prepare_wheel_metadata is completely
>> >> useless AFAIK.
>> >>
>> >> So why is 'setup.py dist_info' a blocker for things?
>> >>
>> >> -n
>> >>
>> >> --
>> >> Nathaniel J. Smith -- https://vorpus.org
>> >
>> >
>>
>>
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>>
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[xoviat]

> The only reason I can think of that setuptools would need a dist_info
command would be to implement the PEP 517 prepare_wheel_metadata hook.

Yes. That is absolutely correct.

> But this hook is optional and in fact provides no value right now, so
it can't be a blocker for anything.

The simplest way to start on this issue is to replace egg_info in pip with
prepare_metadata_for_build_wheel. It is absolutely a historical artifact
but I need to work on one issue at a time. The next issue will be replacing
egg_info in pip with prepare_metadata_for_build_wheel.

2017-09-04 19:34 GMT-05:00 Nathaniel Smith :

> On Mon, Sep 4, 2017 at 5:09 PM, xoviat  wrote:
> > Nathaniel:
> >
> > Pip requires egg_info to discover dependencies of source distributions so
> > that it can build wheels all at once after downloading the requirements.
> I
> > need to move pip off of egg_info as soon as possible and dist_info is
> > required to do that.
>
> "Requires" is a strong word -- AFAIK this is just a historical
> artifact. I don't really know what you're talking about in the second
> sentence.
>
> The only reason I can think of that setuptools would need a dist_info
> command would be to implement the PEP 517 prepare_wheel_metadata hook.
> But this hook is optional and in fact provides no value right now, so
> it can't be a blocker for anything. (In fact I can't see any reason
> why pip would ever call it before the resolver lands.) So either (a)
> there's some other reason you want a dist_info command, (b) there's
> some reason I'm missing why prepare_wheel_metadata matters, or (c) one
> of us is misunderstanding something :-).
>
> -n
>
> > 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
> >>
> >> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
> >> > Just an update for everyone here:
> >> >
> >> > 1. We're currently waiting on the implementation of the 'dist_info"
> >> > command
> >> > in the wheel project.
> >> > 2. Once that is done we can switch pip over to reading dist-info
> rather
> >> > than
> >> > egg_info.
> >> > 3. Then we can move the backend over to setuptools. Because Jacob has
> a
> >> > much
> >> > more efficient release system than pip, I anticipate having a release
> of
> >> > setuptools first and then we can switch pip over to requiring a newer
> >> > setuptools via PEP 518.
> >>
> >> I don't think pip actually has any use for the PEP 517
> >> prepare_wheel_metadata hook right now though? Historically 'setup.py
> >> egg-info' was needed to kluge around unwanted behavior in 'setup.py
> >> install', but with a PEP 517 backend that's irrelevant because
> >> 'setup.py install' is never used. And in the future when pip has a
> >> real resolver, then prepare_wheel_metadata should allow some
> >> optimizations. But right now, prepare_wheel_metadata is completely
> >> useless AFAIK.
> >>
> >> So why is 'setup.py dist_info' a blocker for things?
> >>
> >> -n
> >>
> >> --
> >> Nathaniel J. Smith -- https://vorpus.org
> >
> >
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[Nathaniel Smith]

On Mon, Sep 4, 2017 at 5:09 PM, xoviat  wrote:
> Nathaniel:
>
> Pip requires egg_info to discover dependencies of source distributions so
> that it can build wheels all at once after downloading the requirements. I
> need to move pip off of egg_info as soon as possible and dist_info is
> required to do that.

"Requires" is a strong word -- AFAIK this is just a historical
artifact. I don't really know what you're talking about in the second
sentence.

The only reason I can think of that setuptools would need a dist_info
command would be to implement the PEP 517 prepare_wheel_metadata hook.
But this hook is optional and in fact provides no value right now, so
it can't be a blocker for anything. (In fact I can't see any reason
why pip would ever call it before the resolver lands.) So either (a)
there's some other reason you want a dist_info command, (b) there's
some reason I'm missing why prepare_wheel_metadata matters, or (c) one
of us is misunderstanding something :-).

-n

> 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
>>
>> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
>> > Just an update for everyone here:
>> >
>> > 1. We're currently waiting on the implementation of the 'dist_info"
>> > command
>> > in the wheel project.
>> > 2. Once that is done we can switch pip over to reading dist-info rather
>> > than
>> > egg_info.
>> > 3. Then we can move the backend over to setuptools. Because Jacob has a
>> > much
>> > more efficient release system than pip, I anticipate having a release of
>> > setuptools first and then we can switch pip over to requiring a newer
>> > setuptools via PEP 518.
>>
>> I don't think pip actually has any use for the PEP 517
>> prepare_wheel_metadata hook right now though? Historically 'setup.py
>> egg-info' was needed to kluge around unwanted behavior in 'setup.py
>> install', but with a PEP 517 backend that's irrelevant because
>> 'setup.py install' is never used. And in the future when pip has a
>> real resolver, then prepare_wheel_metadata should allow some
>> optimizations. But right now, prepare_wheel_metadata is completely
>> useless AFAIK.
>>
>> So why is 'setup.py dist_info' a blocker for things?
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>
>



-- 
Nathaniel J. Smith -- https://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[xoviat]

Also if someone with pip write access could please discuss and hopefully
merge my initial PR on pip, I would very much appreciate it. Paul seems to
be short on time.

2017-09-04 19:09 GMT-05:00 xoviat :

> Nathaniel:
>
> Pip requires egg_info to discover dependencies of source distributions so
> that it can build wheels all at once after downloading the requirements. I
> need to move pip off of egg_info as soon as possible and dist_info is
> required to do that.
>
> 2017-09-03 21:00 GMT-05:00 Nathaniel Smith :
>
>> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
>> > Just an update for everyone here:
>> >
>> > 1. We're currently waiting on the implementation of the 'dist_info"
>> command
>> > in the wheel project.
>> > 2. Once that is done we can switch pip over to reading dist-info rather
>> than
>> > egg_info.
>> > 3. Then we can move the backend over to setuptools. Because Jacob has a
>> much
>> > more efficient release system than pip, I anticipate having a release of
>> > setuptools first and then we can switch pip over to requiring a newer
>> > setuptools via PEP 518.
>>
>> I don't think pip actually has any use for the PEP 517
>> prepare_wheel_metadata hook right now though? Historically 'setup.py
>> egg-info' was needed to kluge around unwanted behavior in 'setup.py
>> install', but with a PEP 517 backend that's irrelevant because
>> 'setup.py install' is never used. And in the future when pip has a
>> real resolver, then prepare_wheel_metadata should allow some
>> optimizations. But right now, prepare_wheel_metadata is completely
>> useless AFAIK.
>>
>> So why is 'setup.py dist_info' a blocker for things?
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>>
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[xoviat]

Nathaniel:

Pip requires egg_info to discover dependencies of source distributions so
that it can build wheels all at once after downloading the requirements. I
need to move pip off of egg_info as soon as possible and dist_info is
required to do that.

2017-09-03 21:00 GMT-05:00 Nathaniel Smith :

> On Sun, Sep 3, 2017 at 11:14 AM, xoviat  wrote:
> > Just an update for everyone here:
> >
> > 1. We're currently waiting on the implementation of the 'dist_info"
> command
> > in the wheel project.
> > 2. Once that is done we can switch pip over to reading dist-info rather
> than
> > egg_info.
> > 3. Then we can move the backend over to setuptools. Because Jacob has a
> much
> > more efficient release system than pip, I anticipate having a release of
> > setuptools first and then we can switch pip over to requiring a newer
> > setuptools via PEP 518.
>
> I don't think pip actually has any use for the PEP 517
> prepare_wheel_metadata hook right now though? Historically 'setup.py
> egg-info' was needed to kluge around unwanted behavior in 'setup.py
> install', but with a PEP 517 backend that's irrelevant because
> 'setup.py install' is never used. And in the future when pip has a
> real resolver, then prepare_wheel_metadata should allow some
> optimizations. But right now, prepare_wheel_metadata is completely
> useless AFAIK.
>
> So why is 'setup.py dist_info' a blocker for things?
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Migrating interoperability specs to packaging.python.org

[Daniel Holth]

Well, none of the metadata generated by bdist wheel conforms to an accepted
pep. But if you rely on the json file then you won't be interoperable with
wheels from any other generator.

On Mon, Sep 4, 2017, 10:06 Alex Grönholm  wrote:

> Yes, I see the inclusion of a metadata file which conforms to an
> unaccepted PEP as potentially dangerous.
>
> Perhaps I should disable it in the next release?
>
> Daniel Holth kirjoitti 04.09.2017 klo 17:03:
>
> Some people enjoy using metadata.json which tracked pep 426 but I have
> been meaning to take it out, and perhaps keep the key/value to json
> converter as a command.
>
> On Mon, Sep 4, 2017, 09:33 Nick Coghlan  wrote:
>
>> Some time ago, I started the process [1] of adjusting how
>> distutils-sig uses the PEP process so that the reference
>> specifications will live on packaging.python.org, and we use the PEP
>> process to manage *changes* to those specifications, rather than
>> serving as the specifications themselves (that is, adopting a process
>> closer to the URL-centric way the Python language reference is
>> managed, rather than using the RFCstyle PEP-number-centric model the
>> way we do now).
>>
>> I never actually finished that work, and as a result, it's currently
>> thoroughly unclear [2] that Description-Content-Type and
>> Provides-Extra are defined at
>> https://packaging.python.org/specifications/#core-metadata rather than
>> in a PEP.
>>
>> I'm currently at the CPython core development sprint in San Francisco,
>> and I'm thinking that finalising that migration [3] and updating the
>> affected PEPs accordingly (most notably, PEP 345) is likely to be a
>> good use of my time.
>>
>> However, I'm also wondering if it may still be worthwhile writing a
>> metadata 1.3 PEP that does the following things:
>>
>> 1. Explicitly notes the addition of the two new fields
>> 2. Describes the process change for packaging interoperability
>> specifications
>> 3. Defines a canonical transformation between the human-readable
>> key:value format and a more automation friendly JSON format
>>
>> That PEP would then essentially be the first one to use the new
>> process: it would supersede PEP 345 as the latest metadata
>> specification, but it would *also* redirect readers to the relevant
>> URL on packaging.python.org as the canonical source of the
>> specification, rather than being the reference documentation in its
>> own right.
>>
>> Cheers,
>> Nick.
>>
>> [1] https://github.com/pypa/pypa.io/issues/11#issuecomment-173833061
>> [2] https://github.com/python/peps/issues/388
>>
>> P.S. Daniel, if you're currently thinking "I proposed defining an
>> incremental metadata 1.3 tweak years ago!", aye, you did. My
>> subsequent additions to PEP 426 were a classic case of second-system
>> syndrome: https://en.wikipedia.org/wiki/Second-system_effect (which we
>> suspected long ago, hence that PEP's original deferral)
>>
>> Fortunately, the disciplining effect of working with a primarily
>> volunteer contributor base has prevented my over-engineered
>> change-for-change's-sake-rather-than-to-solve-actual-user-problems
>> version from becoming reality ;)
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
> ___
> Distutils-SIG maillist  -  
> Distutils-SIG@python.orghttps://mail.python.org/mailman/listinfo/distutils-sig
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Migrating interoperability specs to packaging.python.org

[Alex Grönholm]

Yes, I see the inclusion of a metadata file which conforms to an 
unaccepted PEP as potentially dangerous.


Perhaps I should disable it in the next release?


Daniel Holth kirjoitti 04.09.2017 klo 17:03:


Some people enjoy using metadata.json which tracked pep 426 but I have 
been meaning to take it out, and perhaps keep the key/value to json 
converter as a command.



On Mon, Sep 4, 2017, 09:33 Nick Coghlan > wrote:


Some time ago, I started the process [1] of adjusting how
distutils-sig uses the PEP process so that the reference
specifications will live on packaging.python.org
, and we use the PEP
process to manage *changes* to those specifications, rather than
serving as the specifications themselves (that is, adopting a process
closer to the URL-centric way the Python language reference is
managed, rather than using the RFCstyle PEP-number-centric model the
way we do now).

I never actually finished that work, and as a result, it's currently
thoroughly unclear [2] that Description-Content-Type and
Provides-Extra are defined at
https://packaging.python.org/specifications/#core-metadata rather than
in a PEP.

I'm currently at the CPython core development sprint in San Francisco,
and I'm thinking that finalising that migration [3] and updating the
affected PEPs accordingly (most notably, PEP 345) is likely to be a
good use of my time.

However, I'm also wondering if it may still be worthwhile writing a
metadata 1.3 PEP that does the following things:

1. Explicitly notes the addition of the two new fields
2. Describes the process change for packaging interoperability
specifications
3. Defines a canonical transformation between the human-readable
key:value format and a more automation friendly JSON format

That PEP would then essentially be the first one to use the new
process: it would supersede PEP 345 as the latest metadata
specification, but it would *also* redirect readers to the relevant
URL on packaging.python.org  as the
canonical source of the
specification, rather than being the reference documentation in its
own right.

Cheers,
Nick.

[1] https://github.com/pypa/pypa.io/issues/11#issuecomment-173833061
[2] https://github.com/python/peps/issues/388

P.S. Daniel, if you're currently thinking "I proposed defining an
incremental metadata 1.3 tweak years ago!", aye, you did. My
subsequent additions to PEP 426 were a classic case of second-system
syndrome: https://en.wikipedia.org/wiki/Second-system_effect (which we
suspected long ago, hence that PEP's original deferral)

Fortunately, the disciplining effect of working with a primarily
volunteer contributor base has prevented my over-engineered
change-for-change's-sake-rather-than-to-solve-actual-user-problems
version from becoming reality ;)

--
Nick Coghlan   | ncogh...@gmail.com 
 |   Brisbane, Australia
___
Distutils-SIG maillist  - Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Migrating interoperability specs to packaging.python.org

[Daniel Holth]

Some people enjoy using metadata.json which tracked pep 426 but I have been
meaning to take it out, and perhaps keep the key/value to json converter as
a command.

On Mon, Sep 4, 2017, 09:33 Nick Coghlan  wrote:

> Some time ago, I started the process [1] of adjusting how
> distutils-sig uses the PEP process so that the reference
> specifications will live on packaging.python.org, and we use the PEP
> process to manage *changes* to those specifications, rather than
> serving as the specifications themselves (that is, adopting a process
> closer to the URL-centric way the Python language reference is
> managed, rather than using the RFCstyle PEP-number-centric model the
> way we do now).
>
> I never actually finished that work, and as a result, it's currently
> thoroughly unclear [2] that Description-Content-Type and
> Provides-Extra are defined at
> https://packaging.python.org/specifications/#core-metadata rather than
> in a PEP.
>
> I'm currently at the CPython core development sprint in San Francisco,
> and I'm thinking that finalising that migration [3] and updating the
> affected PEPs accordingly (most notably, PEP 345) is likely to be a
> good use of my time.
>
> However, I'm also wondering if it may still be worthwhile writing a
> metadata 1.3 PEP that does the following things:
>
> 1. Explicitly notes the addition of the two new fields
> 2. Describes the process change for packaging interoperability
> specifications
> 3. Defines a canonical transformation between the human-readable
> key:value format and a more automation friendly JSON format
>
> That PEP would then essentially be the first one to use the new
> process: it would supersede PEP 345 as the latest metadata
> specification, but it would *also* redirect readers to the relevant
> URL on packaging.python.org as the canonical source of the
> specification, rather than being the reference documentation in its
> own right.
>
> Cheers,
> Nick.
>
> [1] https://github.com/pypa/pypa.io/issues/11#issuecomment-173833061
> [2] https://github.com/python/peps/issues/388
>
> P.S. Daniel, if you're currently thinking "I proposed defining an
> incremental metadata 1.3 tweak years ago!", aye, you did. My
> subsequent additions to PEP 426 were a classic case of second-system
> syndrome: https://en.wikipedia.org/wiki/Second-system_effect (which we
> suspected long ago, hence that PEP's original deferral)
>
> Fortunately, the disciplining effect of working with a primarily
> volunteer contributor base has prevented my over-engineered
> change-for-change's-sake-rather-than-to-solve-actual-user-problems
> version from becoming reality ;)
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonhosted.org doc upload no longer works

[Nick Coghlan]

On 2 September 2017 at 15:34, Giampaolo Rodola'  wrote:
> I know it was deprecated long ago in favor of readthedocs but I kept
> postponing it and my doc is still hosted on
> https://pythonhosted.org/psutil/.

While we've talked about deprecating it, it *hasn't* been deprecated.
Looking at https://github.com/pypa/pypi-legacy/commits/production, I'm
not seeing anything obvious that would have caused problems with docs
management, but that's probably still the best issue tracker to use to
report the bug.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Migrating interoperability specs to packaging.python.org

[Nick Coghlan]

Some time ago, I started the process [1] of adjusting how
distutils-sig uses the PEP process so that the reference
specifications will live on packaging.python.org, and we use the PEP
process to manage *changes* to those specifications, rather than
serving as the specifications themselves (that is, adopting a process
closer to the URL-centric way the Python language reference is
managed, rather than using the RFCstyle PEP-number-centric model the
way we do now).

I never actually finished that work, and as a result, it's currently
thoroughly unclear [2] that Description-Content-Type and
Provides-Extra are defined at
https://packaging.python.org/specifications/#core-metadata rather than
in a PEP.

I'm currently at the CPython core development sprint in San Francisco,
and I'm thinking that finalising that migration [3] and updating the
affected PEPs accordingly (most notably, PEP 345) is likely to be a
good use of my time.

However, I'm also wondering if it may still be worthwhile writing a
metadata 1.3 PEP that does the following things:

1. Explicitly notes the addition of the two new fields
2. Describes the process change for packaging interoperability specifications
3. Defines a canonical transformation between the human-readable
key:value format and a more automation friendly JSON format

That PEP would then essentially be the first one to use the new
process: it would supersede PEP 345 as the latest metadata
specification, but it would *also* redirect readers to the relevant
URL on packaging.python.org as the canonical source of the
specification, rather than being the reference documentation in its
own right.

Cheers,
Nick.

[1] https://github.com/pypa/pypa.io/issues/11#issuecomment-173833061
[2] https://github.com/python/peps/issues/388

P.S. Daniel, if you're currently thinking "I proposed defining an
incremental metadata 1.3 tweak years ago!", aye, you did. My
subsequent additions to PEP 426 were a classic case of second-system
syndrome: https://en.wikipedia.org/wiki/Second-system_effect (which we
suspected long ago, hence that PEP's original deferral)

Fortunately, the disciplining effect of working with a primarily
volunteer contributor base has prevented my over-engineered
change-for-change's-sake-rather-than-to-solve-actual-user-problems
version from becoming reality ;)

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 517 again

[Nick Coghlan]

On 3 September 2017 at 05:42, Donald Stufft  wrote:
> On Sep 1, 2017, at 2:30 PM, Chris Barker  wrote:
>> Do the Linux distros use pip to build their packages?
>
> Not that I am aware of.

Fedora's build macros for Python projects currently rely on running
setup.py directly, but we've been considering switching to pip instead
since 2013 or so. PEP 517 is likely to provide the impetus to switch
from "maybe we should do that" to "we need to do that, at least if
setup.py is missing, and potentially always, so we get more consistent
installation metadata"

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig