[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Brett Cannon]

My point is I don't think enough pieces are in place to force everyone over
to --no-isolation to get by if they don't set up pyproject.toml as you're
suggesting they be required to. IOW I think you're advocating something
that's going to alienate people by pushing too hard.

On Mon, Jul 16, 2018, 19:30 Pradyun Gedam,  wrote:

>
>
> On Tue, 17 Jul 2018, 00:45 Brett Cannon,  wrote:
>
>>
>>
>> On Mon, 16 Jul 2018 at 10:47 Pradyun Gedam  wrote:
>>
>>>
>>>
>>> On Mon, 16 Jul 2018, 21:11 Paul Moore,  wrote:
>>>
 On 16 July 2018 at 15:56, Pradyun Gedam  wrote:
 >
 > On Mon, 16 Jul 2018, 20:16 Brett Cannon,  wrote:
 >>
 >> I will update the PEP and add you as a reviewer, Paul (might not get
 to it
 >> until Friday, though).
 >>
 >> On Mon, Jul 16, 2018, 02:23 Paul Moore,  wrote:
 >>>
 >>> The discussion on this appears to have died down.
 >>>
 >>> As far as I can tell, the consensus is essentially:
 >>>
 >>> 1. It should be legal for pyproject.toml to *not* contain a
 >>> [build-system] section.
 >>> 2. If a [build-system] section is present, the requires key must be
 >>> present.
 >>>
 >>> Tools should behave as follows:
 >>>
 >>> 1. If [build-system] is present but requires is missing, raise an
 error.
 >>> 2. If [build-system] is missing, they can take one of the following
 >>> two approaches:
 >>>a) Act as if pyproject.toml is missing altogether
 >>>b) Act as if [build-system] is present, with a requires value of
 >>> ["setuptools", "wheel"]
 >>>
 >>> Whether tools act differently in cases 2a and 2b is tool-dependent
 >>> (for pip, we would isolate in case 2b but not in case 2a) which is
 why
 >>> the choice is left to individual tools. That makes the
 >>> "Thomas/Nathaniel" debate into a tool implementation choice, and
 both
 >>> of the options are allowable from the perspective of the PEP.
 >>>
 >>> Is everyone OK with this resolution? If so, will someone raise a PR
 >>> for PEP 518? I can do that if no-one else can.
 >
 > While I don't mind if we'd go ahead with this (and 2b, to not change
 > existing behavior), I still think making the key mandatory would be a
 > good/better idea.

 I get the feeling that no-one is sufficiently motivated to argue
 strongly for any particular resolution - which is why my summary is
 basically "accept the current behaviour as correct" :-)

>>>
>>> I just perceive this as a case of - there's a nicer and arguably,
>>> cleaner option and there's not much cost to getting there. Let's do that. :)
>>>
>>> I don't mind the status quo though.
>>>
>>>
 > The visibility (and hence familiarity) that this would gain from the
 > specification of build-system.requires being mandatory would be nice
 to
 > have. I feel that this would otherwise be a missed opportunity to
 push for
 > the key and standard to be more visible to users and packagers.

 But adoption of pyproject.toml as a standard configuration file by
 projects like towncrier and black is doing that already.

>>>
>>> I'm referring to familiarity with the build-system table (through
>>> build-system.requires being mandatory). If you have to add that table/key
>>> when using those tools, people who work on those projects get to know about
>>> the table.
>>>
>>>
 > The transitory cost for existing packages that break due to this being
 > mandatory would probably be fairly minor (I realize that this point
 is where
 > I dwelled into implementation details earlier, so I'll not digress
 there
 > now).

 I believe the transition costs for projects (and their users) using
 pyproject.toml for config only are:

 Optional, only isolate if [build-system] is present: None
 Optional, isolate if pyproject.toml is present: The few *end users*
 for whom isolation breaks the build have to pass --no-build-isolation
 Mandatory: The *project* has to add the [build-system] section, and
 make a new release. End users have to wait for that release.

>>>
>>> Not really. With mandatory, you can use --no-isolation - it would still
>>> work fine for basically every user that has setuptools and wheel installed
>>> in their current environment (that's almost every environment I'd say).
>>>
>>>
 If I've got that right, the costs for making the key mandatory are a
 lot higher.
>>>
>>>
>>> My intuition/feeling here is that this cost is worth the network effects
>>> that would make more users familiar with them.
>>>
>>
>> I don't think all the pieces are quite there yet. E.g. there is no `pip
>> sdist` to go with `pip wheel`, so we still have some work to do before we
>> can really push people to entirely drop the old way of do things with
>> minimal penalty.
>>
>
> I do agree that not having all pieces is a problem for users currently
> (early adopters) 

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Pradyun Gedam]

On Tue, 17 Jul 2018, 00:45 Brett Cannon,  wrote:

>
>
> On Mon, 16 Jul 2018 at 10:47 Pradyun Gedam  wrote:
>
>>
>>
>> On Mon, 16 Jul 2018, 21:11 Paul Moore,  wrote:
>>
>>> On 16 July 2018 at 15:56, Pradyun Gedam  wrote:
>>> >
>>> > On Mon, 16 Jul 2018, 20:16 Brett Cannon,  wrote:
>>> >>
>>> >> I will update the PEP and add you as a reviewer, Paul (might not get
>>> to it
>>> >> until Friday, though).
>>> >>
>>> >> On Mon, Jul 16, 2018, 02:23 Paul Moore,  wrote:
>>> >>>
>>> >>> The discussion on this appears to have died down.
>>> >>>
>>> >>> As far as I can tell, the consensus is essentially:
>>> >>>
>>> >>> 1. It should be legal for pyproject.toml to *not* contain a
>>> >>> [build-system] section.
>>> >>> 2. If a [build-system] section is present, the requires key must be
>>> >>> present.
>>> >>>
>>> >>> Tools should behave as follows:
>>> >>>
>>> >>> 1. If [build-system] is present but requires is missing, raise an
>>> error.
>>> >>> 2. If [build-system] is missing, they can take one of the following
>>> >>> two approaches:
>>> >>>a) Act as if pyproject.toml is missing altogether
>>> >>>b) Act as if [build-system] is present, with a requires value of
>>> >>> ["setuptools", "wheel"]
>>> >>>
>>> >>> Whether tools act differently in cases 2a and 2b is tool-dependent
>>> >>> (for pip, we would isolate in case 2b but not in case 2a) which is
>>> why
>>> >>> the choice is left to individual tools. That makes the
>>> >>> "Thomas/Nathaniel" debate into a tool implementation choice, and both
>>> >>> of the options are allowable from the perspective of the PEP.
>>> >>>
>>> >>> Is everyone OK with this resolution? If so, will someone raise a PR
>>> >>> for PEP 518? I can do that if no-one else can.
>>> >
>>> > While I don't mind if we'd go ahead with this (and 2b, to not change
>>> > existing behavior), I still think making the key mandatory would be a
>>> > good/better idea.
>>>
>>> I get the feeling that no-one is sufficiently motivated to argue
>>> strongly for any particular resolution - which is why my summary is
>>> basically "accept the current behaviour as correct" :-)
>>>
>>
>> I just perceive this as a case of - there's a nicer and arguably, cleaner
>> option and there's not much cost to getting there. Let's do that. :)
>>
>> I don't mind the status quo though.
>>
>>
>>> > The visibility (and hence familiarity) that this would gain from the
>>> > specification of build-system.requires being mandatory would be nice to
>>> > have. I feel that this would otherwise be a missed opportunity to push
>>> for
>>> > the key and standard to be more visible to users and packagers.
>>>
>>> But adoption of pyproject.toml as a standard configuration file by
>>> projects like towncrier and black is doing that already.
>>>
>>
>> I'm referring to familiarity with the build-system table (through
>> build-system.requires being mandatory). If you have to add that table/key
>> when using those tools, people who work on those projects get to know about
>> the table.
>>
>>
>>> > The transitory cost for existing packages that break due to this being
>>> > mandatory would probably be fairly minor (I realize that this point is
>>> where
>>> > I dwelled into implementation details earlier, so I'll not digress
>>> there
>>> > now).
>>>
>>> I believe the transition costs for projects (and their users) using
>>> pyproject.toml for config only are:
>>>
>>> Optional, only isolate if [build-system] is present: None
>>> Optional, isolate if pyproject.toml is present: The few *end users*
>>> for whom isolation breaks the build have to pass --no-build-isolation
>>> Mandatory: The *project* has to add the [build-system] section, and
>>> make a new release. End users have to wait for that release.
>>>
>>
>> Not really. With mandatory, you can use --no-isolation - it would still
>> work fine for basically every user that has setuptools and wheel installed
>> in their current environment (that's almost every environment I'd say).
>>
>>
>>> If I've got that right, the costs for making the key mandatory are a
>>> lot higher.
>>
>>
>> My intuition/feeling here is that this cost is worth the network effects
>> that would make more users familiar with them.
>>
>
> I don't think all the pieces are quite there yet. E.g. there is no `pip
> sdist` to go with `pip wheel`, so we still have some work to do before we
> can really push people to entirely drop the old way of do things with
> minimal penalty.
>

I do agree that not having all pieces is a problem for users currently
(early adopters) and we should try to get to the point where you can
entirely drop the "old way" sooner than later. :)

I feel like you're making a point here that I'm not able to understand what
for. This is still going to hold true with status quo until we do that work
so this doesn't count against mandatory requires per se. The additional
visibility of this won't be a strong push IMO until this does become a
feasible alternative.

Pradyun


> -Brett
>
>
>>
>> Pradyun
>>
>>

[Distutils]Package maintainers: verify your PyPI account email address

[Sumana Harihareswara]

Heads-up: if you have a pypi.org or test.pypi.org account, please verify your 
email address:

  https://pypi.org/manage/account/

  https://test.pypi.org/manage/account/

Reason:

> We have a problem with a bit of our data, namely that due to historical 
> reasons we have a fair amount of users in the database that do not have a 
> verified primary email address. The side effect of this is that we're 
> currently sending emails to email addresses that we have not had verified. 
> This is a bad situation to be in, because in order to keep our bounce/spam 
> rate low, we should be confirming all email addresses before sending email to 
> them. In addition the way our bounce handling code works is it un-verifies 
> the email address, which the intent was to stop sending email to it until the 
> user has reverified their email address.
> 
> In total there are about 193k user accounts with a unverified email address 
> for their primary address, and 44k that do have a verified email address for 
> their primary account.
> 
> So we need to come up with a strategy to resolve this, because it's pretty 
> important that we don't send email to unverified addresses.

(quoting from Donald Stufft's explanation 
https://github.com/pypa/warehouse/issues/3632 which goes on to detail the 
step-by-step plan)

Package maintainers should especially do this soon. As of a few days ago, any 
user whose primary email address is unverified can't upload a file: 
https://github.com/pypa/warehouse/pull/4292 

Please forward to other package maintainers.

After we iron out any issues I figure we'll email the announce list 
https://mail.python.org/mm3/mailman3/lists/pypi-announce.python.org/ .

-- 
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/5ER2YET54CSX4FV2VP24JA57REDDW5OI/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Nathaniel Smith]

On Mon, Jul 16, 2018 at 11:27 AM, Donald Stufft  wrote:
>
> On Jul 16, 2018, at 5:22 AM, Paul Moore  wrote:
>
>> 1. If [build-system] is present but requires is missing, raise an error.
>> 2. If [build-system] is missing, they can take one of the following
>> two approaches:
>>   a) Act as if pyproject.toml is missing altogether
>>   b) Act as if [build-system] is present, with a requires value of
>> ["setuptools", "wheel"]
>>
>> Whether tools act differently in cases 2a and 2b is tool-dependent
>> (for pip, we would isolate in case 2b but not in case 2a) which is why
>> the choice is left to individual tools. That makes the
>> "Thomas/Nathaniel" debate into a tool implementation choice, and both
>> of the options are allowable from the perspective of the PEP.
>
> This sounds fine to me, and I prefer a 2b approach.

I also prefer option 2 (and specifically 2b but like you say, 2a vs 2b
isn't something the PEP cares about), just because it's the simplest
possible approach: we always act the same when build-system.requires
is missing, regardless of why it's missing. And it's the same logic as
we use to handle a missing build-system.build-backend.

It doesn't matter that much though. It seems extremely unlikely that
anyone's going to create an empty [build-system] section just because
they can...

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/5E6O2PKSQEAK232INZLTOJESOJDFYHKK/

[Distutils]Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

[Nick Terrell]

On Mon, Jul 16, 2018 at 3:56 PM, Barry Warsaw  wrote:
> * How do you achieve faster hot start times with XAR over native file
> system?  That's a bit unexpected, although based on our shiv work, I can
> imagine some things about how you start Python or lay out the code that
> might provide better hot start times (e.g. fewer entries on sys.path and a
> fanatical avoidance of pkg_resources).  OTOH, I'd think that relying on FUSE
> would impose some additional overhead over native file systems.

Hi all,

I collected the XAR benchmark numbers. I spent some time today
investigating what
exactly is causing the difference between native and XAR start times. The native
installation I was benchmarking against used `pkg_resources.load_entry_point()`
to run the script, while XAR called the entry point directly.

I didn't realize that `pip install .` behavior differs based on
whether `wheel` is
installed or not. When wheel is installed pip uses `bdist_wheel` to
build the package
and uses its own loader script which calls the entry point directly.
When it isn't it
uses `python setup.py install` to build the package and uses the
setuptools loader
script which use `pkg_resources.load_entry_point()` to call the script.

If I rerun the experiment with the wheel loader script (without pkg_resources),
I see these hot start times:

black: 0.171 s (vs 0.208 for XAR)
jupyter-nbextension: 0.165 s (vs 0.179 s for XAR)

Without the pkg_resources difference we have a small overhead over
native installs.

Best,
Nick
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/E7J7NP4VVHYPSALAFREO53QUO6FIM6PK/

[Distutils]Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

[Cooper Ry Lees]

Hi Barry,

I'm aware of shiv, thus my "and other zip based distribution methods."

Also, you're welcome to come and meet and greet with XAR people if you want to 
know all the ins and outs here on campus. We're not far away + I'm always in 
pypa-dev + can use that Twitter thing :)

Specific answers below.

> On Jul 16, 2018, at 3:56 PM, Barry Warsaw  wrote:
> 
> Cooper Ry Lees wrote on 7/13/18 13:51:
> 
>> Today Facebook Open Sourced a competitor to PEX and other zip based 
>> distribution methods for Python (and potentially other languages). Basically 
>> it's claim to fame is start up time for large modules being similar to 
>> regular on file system modules due to extracting on read via SquashFS 
>> mounted executables. For more information read our blog post:
>> - 
>> https://code.fb.com/data-infrastructure/xars-a-more-efficient-open-source-system-for-self-contained-executables/
>>  
>> 
> 
> This is really interesting!  Thanks for releasing it and announcing it. I 
> should mention that LinkedIn (my day job) recently released 'shiv' as a more 
> modern, and in our case much faster, zipapp container similar to pex.
> 
> http://shiv.readthedocs.io/en/latest/
> 
> I have some quick questions about XAR:
> 
> * How do you achieve faster hot start times with XAR over native file system? 
>  That's a bit unexpected, although based on our shiv work, I can imagine some 
> things about how you start Python or lay out the code that might provide 
> better hot start times (e.g. fewer entries on sys.path and a fanatical 
> avoidance of pkg_resources).  OTOH, I'd think that relying on FUSE would 
> impose some additional overhead over native file systems.
> 
I usually only see similar start times to native file system, sometimes only 
slightly faster. Our numbers published are probably on modules to small to be 
super accurate for all use cases.

> * Is there any practical operational or performance limits on the number of 
> mounted XARs you can have?  E.g. what's the impact of deploying say a few 
> thousand XARs on any particular machine (generally, of Linux and macOS - I'm 
> not as concerned about Windows :)
We have tiers (think of that as a collection of servers for a particular 
service) that have 100s mounted at times. Have not hit 1000s - But have not 
seen any huge problems with 100s. What do your servers do that would need 1000s 
of XARs running at once? Seems like that could be optimized.

> 
> * Do you just put the XAR mountpoint's bin on everyone's $PATH or do you 
> symlink those bins into a standard $PATH location?
Standard PATH location via RPM installs.

> 
> Cheers,
> -Barry
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/7CD3HDYFNIAFWSD4FSSTJQRNGJ7M3TDP/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/76QMPMCSB76KKQK6P2ZPOYIL3AB3WONI/

[Distutils]Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

[Barry Warsaw]

Cooper Ry Lees wrote on 7/13/18 13:51:


Today Facebook Open Sourced a competitor to PEX and other zip based 
distribution methods for Python (and potentially other languages). Basically 
it's claim to fame is start up time for large modules being similar to regular 
on file system modules due to extracting on read via SquashFS mounted 
executables. For more information read our blog post:
- 
https://code.fb.com/data-infrastructure/xars-a-more-efficient-open-source-system-for-self-contained-executables/
 



This is really interesting!  Thanks for releasing it and announcing it. 
I should mention that LinkedIn (my day job) recently released 'shiv' as 
a more modern, and in our case much faster, zipapp container similar to pex.


http://shiv.readthedocs.io/en/latest/

I have some quick questions about XAR:

* How do you achieve faster hot start times with XAR over native file 
system?  That's a bit unexpected, although based on our shiv work, I can 
imagine some things about how you start Python or lay out the code that 
might provide better hot start times (e.g. fewer entries on sys.path and 
a fanatical avoidance of pkg_resources).  OTOH, I'd think that relying 
on FUSE would impose some additional overhead over native file systems.


* Is there any practical operational or performance limits on the number 
of mounted XARs you can have?  E.g. what's the impact of deploying say a 
few thousand XARs on any particular machine (generally, of Linux and 
macOS - I'm not as concerned about Windows :)


* Do you just put the XAR mountpoint's bin on everyone's $PATH or do you 
symlink those bins into a standard $PATH location?


Cheers,
-Barry
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/7CD3HDYFNIAFWSD4FSSTJQRNGJ7M3TDP/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Brett Cannon]

On Mon, 16 Jul 2018 at 10:47 Pradyun Gedam  wrote:

>
>
> On Mon, 16 Jul 2018, 21:11 Paul Moore,  wrote:
>
>> On 16 July 2018 at 15:56, Pradyun Gedam  wrote:
>> >
>> > On Mon, 16 Jul 2018, 20:16 Brett Cannon,  wrote:
>> >>
>> >> I will update the PEP and add you as a reviewer, Paul (might not get
>> to it
>> >> until Friday, though).
>> >>
>> >> On Mon, Jul 16, 2018, 02:23 Paul Moore,  wrote:
>> >>>
>> >>> The discussion on this appears to have died down.
>> >>>
>> >>> As far as I can tell, the consensus is essentially:
>> >>>
>> >>> 1. It should be legal for pyproject.toml to *not* contain a
>> >>> [build-system] section.
>> >>> 2. If a [build-system] section is present, the requires key must be
>> >>> present.
>> >>>
>> >>> Tools should behave as follows:
>> >>>
>> >>> 1. If [build-system] is present but requires is missing, raise an
>> error.
>> >>> 2. If [build-system] is missing, they can take one of the following
>> >>> two approaches:
>> >>>a) Act as if pyproject.toml is missing altogether
>> >>>b) Act as if [build-system] is present, with a requires value of
>> >>> ["setuptools", "wheel"]
>> >>>
>> >>> Whether tools act differently in cases 2a and 2b is tool-dependent
>> >>> (for pip, we would isolate in case 2b but not in case 2a) which is why
>> >>> the choice is left to individual tools. That makes the
>> >>> "Thomas/Nathaniel" debate into a tool implementation choice, and both
>> >>> of the options are allowable from the perspective of the PEP.
>> >>>
>> >>> Is everyone OK with this resolution? If so, will someone raise a PR
>> >>> for PEP 518? I can do that if no-one else can.
>> >
>> > While I don't mind if we'd go ahead with this (and 2b, to not change
>> > existing behavior), I still think making the key mandatory would be a
>> > good/better idea.
>>
>> I get the feeling that no-one is sufficiently motivated to argue
>> strongly for any particular resolution - which is why my summary is
>> basically "accept the current behaviour as correct" :-)
>>
>
> I just perceive this as a case of - there's a nicer and arguably, cleaner
> option and there's not much cost to getting there. Let's do that. :)
>
> I don't mind the status quo though.
>
>
>> > The visibility (and hence familiarity) that this would gain from the
>> > specification of build-system.requires being mandatory would be nice to
>> > have. I feel that this would otherwise be a missed opportunity to push
>> for
>> > the key and standard to be more visible to users and packagers.
>>
>> But adoption of pyproject.toml as a standard configuration file by
>> projects like towncrier and black is doing that already.
>>
>
> I'm referring to familiarity with the build-system table (through
> build-system.requires being mandatory). If you have to add that table/key
> when using those tools, people who work on those projects get to know about
> the table.
>
>
>> > The transitory cost for existing packages that break due to this being
>> > mandatory would probably be fairly minor (I realize that this point is
>> where
>> > I dwelled into implementation details earlier, so I'll not digress there
>> > now).
>>
>> I believe the transition costs for projects (and their users) using
>> pyproject.toml for config only are:
>>
>> Optional, only isolate if [build-system] is present: None
>> Optional, isolate if pyproject.toml is present: The few *end users*
>> for whom isolation breaks the build have to pass --no-build-isolation
>> Mandatory: The *project* has to add the [build-system] section, and
>> make a new release. End users have to wait for that release.
>>
>
> Not really. With mandatory, you can use --no-isolation - it would still
> work fine for basically every user that has setuptools and wheel installed
> in their current environment (that's almost every environment I'd say).
>
>
>> If I've got that right, the costs for making the key mandatory are a
>> lot higher.
>
>
> My intuition/feeling here is that this cost is worth the network effects
> that would make more users familiar with them.
>

I don't think all the pieces are quite there yet. E.g. there is no `pip
sdist` to go with `pip wheel`, so we still have some work to do before we
can really push people to entirely drop the old way of do things with
minimal penalty.

-Brett


>
> Pradyun
>
> The costs for 2b are there, but a lot smaller (and the end
>> user has a workaround). Option 2a has no costs, but also misses the
>> opportunity to move towards build isolation by default for a few extra
>> cases.
>>
>> Paul
>>
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/S5IMBAWPXQ2LS74QIW7CPGJRJO6ZWWDD/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Donald Stufft]

> On Jul 16, 2018, at 5:22 AM, Paul Moore  wrote:
> 
> 1. If [build-system] is present but requires is missing, raise an error.
> 2. If [build-system] is missing, they can take one of the following
> two approaches:
>   a) Act as if pyproject.toml is missing altogether
>   b) Act as if [build-system] is present, with a requires value of
> ["setuptools", "wheel"]
> 
> Whether tools act differently in cases 2a and 2b is tool-dependent
> (for pip, we would isolate in case 2b but not in case 2a) which is why
> the choice is left to individual tools. That makes the
> "Thomas/Nathaniel" debate into a tool implementation choice, and both
> of the options are allowable from the perspective of the PEP.

This sounds fine to me, and I prefer a 2b approach.--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/KZYT4PCU45AHZNW7XBDMFFIJPL3KQM27/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Pradyun Gedam]

On Mon, 16 Jul 2018, 21:11 Paul Moore,  wrote:

> On 16 July 2018 at 15:56, Pradyun Gedam  wrote:
> >
> > On Mon, 16 Jul 2018, 20:16 Brett Cannon,  wrote:
> >>
> >> I will update the PEP and add you as a reviewer, Paul (might not get to
> it
> >> until Friday, though).
> >>
> >> On Mon, Jul 16, 2018, 02:23 Paul Moore,  wrote:
> >>>
> >>> The discussion on this appears to have died down.
> >>>
> >>> As far as I can tell, the consensus is essentially:
> >>>
> >>> 1. It should be legal for pyproject.toml to *not* contain a
> >>> [build-system] section.
> >>> 2. If a [build-system] section is present, the requires key must be
> >>> present.
> >>>
> >>> Tools should behave as follows:
> >>>
> >>> 1. If [build-system] is present but requires is missing, raise an
> error.
> >>> 2. If [build-system] is missing, they can take one of the following
> >>> two approaches:
> >>>a) Act as if pyproject.toml is missing altogether
> >>>b) Act as if [build-system] is present, with a requires value of
> >>> ["setuptools", "wheel"]
> >>>
> >>> Whether tools act differently in cases 2a and 2b is tool-dependent
> >>> (for pip, we would isolate in case 2b but not in case 2a) which is why
> >>> the choice is left to individual tools. That makes the
> >>> "Thomas/Nathaniel" debate into a tool implementation choice, and both
> >>> of the options are allowable from the perspective of the PEP.
> >>>
> >>> Is everyone OK with this resolution? If so, will someone raise a PR
> >>> for PEP 518? I can do that if no-one else can.
> >
> > While I don't mind if we'd go ahead with this (and 2b, to not change
> > existing behavior), I still think making the key mandatory would be a
> > good/better idea.
>
> I get the feeling that no-one is sufficiently motivated to argue
> strongly for any particular resolution - which is why my summary is
> basically "accept the current behaviour as correct" :-)
>

I just perceive this as a case of - there's a nicer and arguably, cleaner
option and there's not much cost to getting there. Let's do that. :)

I don't mind the status quo though.


> > The visibility (and hence familiarity) that this would gain from the
> > specification of build-system.requires being mandatory would be nice to
> > have. I feel that this would otherwise be a missed opportunity to push
> for
> > the key and standard to be more visible to users and packagers.
>
> But adoption of pyproject.toml as a standard configuration file by
> projects like towncrier and black is doing that already.
>

I'm referring to familiarity with the build-system table (through
build-system.requires being mandatory). If you have to add that table/key
when using those tools, people who work on those projects get to know about
the table.


> > The transitory cost for existing packages that break due to this being
> > mandatory would probably be fairly minor (I realize that this point is
> where
> > I dwelled into implementation details earlier, so I'll not digress there
> > now).
>
> I believe the transition costs for projects (and their users) using
> pyproject.toml for config only are:
>
> Optional, only isolate if [build-system] is present: None
> Optional, isolate if pyproject.toml is present: The few *end users*
> for whom isolation breaks the build have to pass --no-build-isolation
> Mandatory: The *project* has to add the [build-system] section, and
> make a new release. End users have to wait for that release.
>

Not really. With mandatory, you can use --no-isolation - it would still
work fine for basically every user that has setuptools and wheel installed
in their current environment (that's almost every environment I'd say).


> If I've got that right, the costs for making the key mandatory are a
> lot higher.


My intuition/feeling here is that this cost is worth the network effects
that would make more users familiar with them.

Pradyun

The costs for 2b are there, but a lot smaller (and the end
> user has a workaround). Option 2a has no costs, but also misses the
> opportunity to move towards build isolation by default for a few extra
> cases.
>
> Paul
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/YJ22D4JIGXLNFCZXCCT22NR67OBRW6F5/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Paul Moore]

On 16 July 2018 at 15:56, Pradyun Gedam  wrote:
>
> On Mon, 16 Jul 2018, 20:16 Brett Cannon,  wrote:
>>
>> I will update the PEP and add you as a reviewer, Paul (might not get to it
>> until Friday, though).
>>
>> On Mon, Jul 16, 2018, 02:23 Paul Moore,  wrote:
>>>
>>> The discussion on this appears to have died down.
>>>
>>> As far as I can tell, the consensus is essentially:
>>>
>>> 1. It should be legal for pyproject.toml to *not* contain a
>>> [build-system] section.
>>> 2. If a [build-system] section is present, the requires key must be
>>> present.
>>>
>>> Tools should behave as follows:
>>>
>>> 1. If [build-system] is present but requires is missing, raise an error.
>>> 2. If [build-system] is missing, they can take one of the following
>>> two approaches:
>>>a) Act as if pyproject.toml is missing altogether
>>>b) Act as if [build-system] is present, with a requires value of
>>> ["setuptools", "wheel"]
>>>
>>> Whether tools act differently in cases 2a and 2b is tool-dependent
>>> (for pip, we would isolate in case 2b but not in case 2a) which is why
>>> the choice is left to individual tools. That makes the
>>> "Thomas/Nathaniel" debate into a tool implementation choice, and both
>>> of the options are allowable from the perspective of the PEP.
>>>
>>> Is everyone OK with this resolution? If so, will someone raise a PR
>>> for PEP 518? I can do that if no-one else can.
>
> While I don't mind if we'd go ahead with this (and 2b, to not change
> existing behavior), I still think making the key mandatory would be a
> good/better idea.

I get the feeling that no-one is sufficiently motivated to argue
strongly for any particular resolution - which is why my summary is
basically "accept the current behaviour as correct" :-)

> The visibility (and hence familiarity) that this would gain from the
> specification of build-system.requires being mandatory would be nice to
> have. I feel that this would otherwise be a missed opportunity to push for
> the key and standard to be more visible to users and packagers.

But adoption of pyproject.toml as a standard configuration file by
projects like towncrier and black is doing that already.

> The transitory cost for existing packages that break due to this being
> mandatory would probably be fairly minor (I realize that this point is where
> I dwelled into implementation details earlier, so I'll not digress there
> now).

I believe the transition costs for projects (and their users) using
pyproject.toml for config only are:

Optional, only isolate if [build-system] is present: None
Optional, isolate if pyproject.toml is present: The few *end users*
for whom isolation breaks the build have to pass --no-build-isolation
Mandatory: The *project* has to add the [build-system] section, and
make a new release. End users have to wait for that release.

If I've got that right, the costs for making the key mandatory are a
lot higher. The costs for 2b are there, but a lot smaller (and the end
user has a workaround). Option 2a has no costs, but also misses the
opportunity to move towards build isolation by default for a few extra
cases.

Paul
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/73VDP2Y455ICOJTEJ5OZZMD4Z6K3QTZ5/

[Distutils](no subject)

[phung237...@gmail.com]

Được gửi từ Yahoo Mail trên Android--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/2XZFRTIXNRXS3H5L4KT7326PL6ADBIXA/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Pradyun Gedam]

On Mon, 16 Jul 2018, 20:16 Brett Cannon,  wrote:

> I will update the PEP and add you as a reviewer, Paul (might not get to it
> until Friday, though).
>
> On Mon, Jul 16, 2018, 02:23 Paul Moore,  wrote:
>
>> The discussion on this appears to have died down.
>>
>> As far as I can tell, the consensus is essentially:
>>
>> 1. It should be legal for pyproject.toml to *not* contain a
>> [build-system] section.
>> 2. If a [build-system] section is present, the requires key must be
>> present.
>>
>> Tools should behave as follows:
>>
>> 1. If [build-system] is present but requires is missing, raise an error.
>> 2. If [build-system] is missing, they can take one of the following
>> two approaches:
>>a) Act as if pyproject.toml is missing altogether
>>b) Act as if [build-system] is present, with a requires value of
>> ["setuptools", "wheel"]
>>
>> Whether tools act differently in cases 2a and 2b is tool-dependent
>> (for pip, we would isolate in case 2b but not in case 2a) which is why
>> the choice is left to individual tools. That makes the
>> "Thomas/Nathaniel" debate into a tool implementation choice, and both
>> of the options are allowable from the perspective of the PEP.
>>
>> Is everyone OK with this resolution? If so, will someone raise a PR
>> for PEP 518? I can do that if no-one else can.
>>
>
While I don't mind if we'd go ahead with this (and 2b, to not change
existing behavior), I still think making the key mandatory would be a
good/better idea.

The visibility (and hence familiarity) that this would gain from the
specification of build-system.requires being mandatory would be nice to
have. I feel that this would otherwise be a missed opportunity to push for
the key and standard to be more visible to users and packagers.

The transitory cost for existing packages that break due to this being
mandatory would probably be fairly minor (I realize that this point is
where I dwelled into implementation details earlier, so I'll not digress
there now).

Pradyun


>> Paul
>>
>> PS Following on from
>>
>> >> I think it would be helpful for this discussion if we could look at
>> these
>> >> bug reports – do does anyone have links?
>> >
>> > Good point. I will hunt them out and post here.
>>
>> I mentioned this on the pip issue, but the only pip problem which has
>> been raised with the current behaviour is around cases where the user
>> disabled PyPI access and doesn't have a local copy of
>> setuptools/wheel, which means we can't build the isolated environment.
>> But that's a corner case that is easily resolvable, and I don't think
>> it needs to affect pip's choice of behaviour (much less what the PEP
>> says).
>>
>>
>> On 10 July 2018 at 08:03, Paul Moore  wrote:
>> > On 10 July 2018 at 05:09, Pradyun Gedam  wrote:
>> >> On Tue, Jul 10, 2018 at 2:30 AM Paul Moore 
>> wrote:
>> >>> For now I'll point out that PEP 518 doesn't say *anything* about how
>> >>> tools use the information in `pyproject.toml` - there's no mention of
>> >>> build isolation. Unless I missed something - please point it out if I
>> >>> did, The only thing I can find is in PEP 517. So discussions of pip's
>> >>> isolation behaviour are mostly pip-specific implementation details at
>> >>> the moment, and not really relevant to this thread.
>> >>
>> >> Ah, okay. So, isolation is purely an implementation issue, so it
>> doesn't
>> >> need to come around in this discussion which is about how we should
>> >> change the PEP. I guess I'm still figuring out where to draw the line
>> >> between implementation details and the PEP details here since they
>> >> should/would influence each other both ways. I'll try to be more
>> careful
>> >> about stuff like this in the future. :)
>> >
>> > Not a problem. Isolation is discussed in PEP 517, which is why I was
>> > getting confused about what was related to the standard and what to
>> > the implementation. We will need to be careful to review all this once
>> > we start implementing PEP 517, but for now at least that's a level of
>> > complexity we don't need in this discussion.
>> >
>> > Paul
>>
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/BERTMHYYQVYW36PKSER5H3TBUDSNMESW/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Brett Cannon]

I will update the PEP and add you as a reviewer, Paul (might not get to it
until Friday, though).

On Mon, Jul 16, 2018, 02:23 Paul Moore,  wrote:

> The discussion on this appears to have died down.
>
> As far as I can tell, the consensus is essentially:
>
> 1. It should be legal for pyproject.toml to *not* contain a
> [build-system] section.
> 2. If a [build-system] section is present, the requires key must be
> present.
>
> Tools should behave as follows:
>
> 1. If [build-system] is present but requires is missing, raise an error.
> 2. If [build-system] is missing, they can take one of the following
> two approaches:
>a) Act as if pyproject.toml is missing altogether
>b) Act as if [build-system] is present, with a requires value of
> ["setuptools", "wheel"]
>
> Whether tools act differently in cases 2a and 2b is tool-dependent
> (for pip, we would isolate in case 2b but not in case 2a) which is why
> the choice is left to individual tools. That makes the
> "Thomas/Nathaniel" debate into a tool implementation choice, and both
> of the options are allowable from the perspective of the PEP.
>
> Is everyone OK with this resolution? If so, will someone raise a PR
> for PEP 518? I can do that if no-one else can.
>
> Paul
>
> PS Following on from
>
> >> I think it would be helpful for this discussion if we could look at
> these
> >> bug reports – do does anyone have links?
> >
> > Good point. I will hunt them out and post here.
>
> I mentioned this on the pip issue, but the only pip problem which has
> been raised with the current behaviour is around cases where the user
> disabled PyPI access and doesn't have a local copy of
> setuptools/wheel, which means we can't build the isolated environment.
> But that's a corner case that is easily resolvable, and I don't think
> it needs to affect pip's choice of behaviour (much less what the PEP
> says).
>
>
> On 10 July 2018 at 08:03, Paul Moore  wrote:
> > On 10 July 2018 at 05:09, Pradyun Gedam  wrote:
> >> On Tue, Jul 10, 2018 at 2:30 AM Paul Moore  wrote:
> >>> For now I'll point out that PEP 518 doesn't say *anything* about how
> >>> tools use the information in `pyproject.toml` - there's no mention of
> >>> build isolation. Unless I missed something - please point it out if I
> >>> did, The only thing I can find is in PEP 517. So discussions of pip's
> >>> isolation behaviour are mostly pip-specific implementation details at
> >>> the moment, and not really relevant to this thread.
> >>
> >> Ah, okay. So, isolation is purely an implementation issue, so it doesn't
> >> need to come around in this discussion which is about how we should
> >> change the PEP. I guess I'm still figuring out where to draw the line
> >> between implementation details and the PEP details here since they
> >> should/would influence each other both ways. I'll try to be more careful
> >> about stuff like this in the future. :)
> >
> > Not a problem. Isolation is discussed in PEP 517, which is why I was
> > getting confused about what was related to the standard and what to
> > the implementation. We will need to be careful to review all this once
> > we start implementing PEP 517, but for now at least that's a level of
> > complexity we don't need in this discussion.
> >
> > Paul
>
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/KU5TPNUFYZYZXWTXZJZD66ZOMAD6XXG6/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Thomas Kluyver]

On Mon, Jul 16, 2018, at 11:50 AM, Paul Moore wrote:
> On 16 July 2018 at 11:05, Thomas Kluyver  wrote:
> > My proposal was 2a ;-). And that's still my inclination, as we've got 
> > examples of people using pyproject.toml for unrelated purposes that 
> > shouldn't affect how the package is built.
> 
> OK. Unless we change pip, that means that the PEP would be suggesting
> that tools use a behaviour different from pip. I'm not comfortable
> with that (which is why I left the choice unspecified) but nor has
> anyone convinced me that pip should change. Real world experience with
> 2b in pip 10 has shown very little in the way of actual issues
> reported by users, and we (pip) *do* want to make isolation the norm
> in the long run.

IIRC pip can't do effective isolation yet, so any problems that do arise from 
this are still largely theoretical. I *am* suggesting that pip should switch to 
2a while this functionality is still new enough to make that relatively 
feasible. I'm not volunteering to make the changes, though, so feel free to 
ignore me. ;-)

Thomas
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/FJOCOFAND3LNUWKHFN7EMVQAF4FHGQJC/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Paul Moore]

On 16 July 2018 at 11:05, Thomas Kluyver  wrote:
> On Mon, Jul 16, 2018, at 11:02 AM, Paul Moore wrote:
>> My inclination would be to recommend 2b. I said that before checking
>> whether that was your proposal or Nathaniel's ;-), and it's based
>> mostly on gut feel and "that's what pip does now and I don't see any
>> reason to change it" though.
>
> My proposal was 2a ;-). And that's still my inclination, as we've got 
> examples of people using pyproject.toml for unrelated purposes that shouldn't 
> affect how the package is built.

OK. Unless we change pip, that means that the PEP would be suggesting
that tools use a behaviour different from pip. I'm not comfortable
with that (which is why I left the choice unspecified) but nor has
anyone convinced me that pip should change. Real world experience with
2b in pip 10 has shown very little in the way of actual issues
reported by users, and we (pip) *do* want to make isolation the norm
in the long run.

I understand your theoretical point, though I don't think it beats the
practical considerations.

Paul
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/J5W4VYS24GEKFRCKENP4P3V5DXSFR7FX/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Thomas Kluyver]

On Mon, Jul 16, 2018, at 11:02 AM, Paul Moore wrote:
> My inclination would be to recommend 2b. I said that before checking
> whether that was your proposal or Nathaniel's ;-), and it's based
> mostly on gut feel and "that's what pip does now and I don't see any
> reason to change it" though.

My proposal was 2a ;-). And that's still my inclination, as we've got examples 
of people using pyproject.toml for unrelated purposes that shouldn't affect how 
the package is built.
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/MJRLVQ6CWNLWGHKRDHVGYLD5P5PIUQJ5/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Paul Moore]

On 16 July 2018 at 10:45, Thomas Kluyver  wrote:
> On Mon, Jul 16, 2018, at 10:22 AM, Paul Moore wrote:
>> 2. If [build-system] is missing, they can take one of the following
>> two approaches:
>>a) Act as if pyproject.toml is missing altogether
>>b) Act as if [build-system] is present, with a requires value of
>> ["setuptools", "wheel"]
>>
>> Whether tools act differently in cases 2a and 2b is tool-dependent
>> (for pip, we would isolate in case 2b but not in case 2a) which is why
>> the choice is left to individual tools. That makes the
>> "Thomas/Nathaniel" debate into a tool implementation choice, and both
>> of the options are allowable from the perspective of the PEP.
>>
>> Is everyone OK with this resolution?
>
> Broadly, yes. I think it might be appropriate for the PEP to make a 
> recommendation between 2a and 2b, even if it's not a hard requirement. In 
> practice, all other tools will probably want to do what pip does, so we don't 
> have packages that one tool can build but another can't.
>
> I'm not going to stamp my foot about this, though.

My inclination would be to recommend 2b. I said that before checking
whether that was your proposal or Nathaniel's ;-), and it's based
mostly on gut feel and "that's what pip does now and I don't see any
reason to change it" though.

Paul
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/S56Y6LECNYZW2OIUEJ5WLQZZP5B6B2SF/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Thomas Kluyver]

On Mon, Jul 16, 2018, at 10:22 AM, Paul Moore wrote:
> 2. If [build-system] is missing, they can take one of the following
> two approaches:
>a) Act as if pyproject.toml is missing altogether
>b) Act as if [build-system] is present, with a requires value of
> ["setuptools", "wheel"]
> 
> Whether tools act differently in cases 2a and 2b is tool-dependent
> (for pip, we would isolate in case 2b but not in case 2a) which is why
> the choice is left to individual tools. That makes the
> "Thomas/Nathaniel" debate into a tool implementation choice, and both
> of the options are allowable from the perspective of the PEP.
> 
> Is everyone OK with this resolution?

Broadly, yes. I think it might be appropriate for the PEP to make a 
recommendation between 2a and 2b, even if it's not a hard requirement. In 
practice, all other tools will probably want to do what pip does, so we don't 
have packages that one tool can build but another can't.

I'm not going to stamp my foot about this, though.

Thomas
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/P6F4LCQV54WZC2YBRRLIISJQTRUZJCHE/

[Distutils]Re: PEP 518 - pyproject.toml with no build-system.requires

[Paul Moore]

The discussion on this appears to have died down.

As far as I can tell, the consensus is essentially:

1. It should be legal for pyproject.toml to *not* contain a
[build-system] section.
2. If a [build-system] section is present, the requires key must be present.

Tools should behave as follows:

1. If [build-system] is present but requires is missing, raise an error.
2. If [build-system] is missing, they can take one of the following
two approaches:
   a) Act as if pyproject.toml is missing altogether
   b) Act as if [build-system] is present, with a requires value of
["setuptools", "wheel"]

Whether tools act differently in cases 2a and 2b is tool-dependent
(for pip, we would isolate in case 2b but not in case 2a) which is why
the choice is left to individual tools. That makes the
"Thomas/Nathaniel" debate into a tool implementation choice, and both
of the options are allowable from the perspective of the PEP.

Is everyone OK with this resolution? If so, will someone raise a PR
for PEP 518? I can do that if no-one else can.

Paul

PS Following on from

>> I think it would be helpful for this discussion if we could look at these
>> bug reports – do does anyone have links?
>
> Good point. I will hunt them out and post here.

I mentioned this on the pip issue, but the only pip problem which has
been raised with the current behaviour is around cases where the user
disabled PyPI access and doesn't have a local copy of
setuptools/wheel, which means we can't build the isolated environment.
But that's a corner case that is easily resolvable, and I don't think
it needs to affect pip's choice of behaviour (much less what the PEP
says).


On 10 July 2018 at 08:03, Paul Moore  wrote:
> On 10 July 2018 at 05:09, Pradyun Gedam  wrote:
>> On Tue, Jul 10, 2018 at 2:30 AM Paul Moore  wrote:
>>> For now I'll point out that PEP 518 doesn't say *anything* about how
>>> tools use the information in `pyproject.toml` - there's no mention of
>>> build isolation. Unless I missed something - please point it out if I
>>> did, The only thing I can find is in PEP 517. So discussions of pip's
>>> isolation behaviour are mostly pip-specific implementation details at
>>> the moment, and not really relevant to this thread.
>>
>> Ah, okay. So, isolation is purely an implementation issue, so it doesn't
>> need to come around in this discussion which is about how we should
>> change the PEP. I guess I'm still figuring out where to draw the line
>> between implementation details and the PEP details here since they
>> should/would influence each other both ways. I'll try to be more careful
>> about stuff like this in the future. :)
>
> Not a problem. Isolation is discussed in PEP 517, which is why I was
> getting confused about what was related to the standard and what to
> the implementation. We will need to be careful to review all this once
> we start implementing PEP 517, but for now at least that's a level of
> complexity we don't need in this discussion.
>
> Paul
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/R4PG3W67CJDRFJU7WUUOCBPDIAXF4KNC/

[Distutils]Re: ssl error in installing packages

[Robin Becker]

On 13/07/2018 05:40, Nitin Thakur wrote:

SSL-CERTIFICATE-VERIFICATION FAILED while installing packages using pip command.


...

Over the weekend Matthew Brett did a fix to the manylinux test image that fixed this issue in the test phase of the manylinux 3.7 
process. The 'fix' involved pip installing certifi and copying the certifi ca file over the openssl file. Many thanks the Matthew.


I think this problem arises now because 3.7 is mandatorily checking 
certificates for urllib requets etc etc.
--
Robin Becker
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/YE6H2AHPWIAIRBH3I4VIJ54S6RBBXT7O/