[Python-Dev] Re: PEP 632: Deprecate distutils module

2020-09-07 Thread Steve Dower

Thanks everyone for your input so far.

Rest assured, I am very aware of air-gapped and limited network systems, 
as well as corporate policies and processes. Having distutils in the 
standard library does not help with any of these.


Do not forget that pip (and presently, though not permanently, 
setuptools) are bundled with a recommended CPython distribution through 
ensurepip. I call out "recommended" because distributors (including 
those who are transferring CPython into an air-gapped system) can choose 
to do whatever they like - including leaving out distutils already!


As for defining standards for installation, the sysconfig module 
specifies the paths to install things (though even those can be taken 
with a grain of salt, as it's really the import system and site module 
that determine where things should be installed), but we already defer 
to third parties to do the actual installation (including, yes, those 
who use distutils to help define their install script). All other 
packaging and distribution specifications are listed at 
https://packaging.python.org/specifications/


Also, distutils has never been a "standard" for how to define a package 
(i.e. write a setup.py), just as argparse is not a "standard" for how to 
define a CLI. It's always been possible to do it in other ways, and the 
current standard definition for this is now PEP 517. Since distutils is 
not compatible with PEP 517, it is explicitly *breaking* the standard.


I also wanted to call out this excellent point from Emily:


If you can update to a breaking Python version, but aren't allowed one single 
point version of an external module, you have a process problem.


This is absolutely the case. CPython, and the core team, cannot take 
responsibility for bad policies, and (arguably) should not help users 
work around those policies. It is better to provide useful advice to 
organisations implementing these policies to help them do things 
properly (this is a large part of what I get paid to do these days), 
because otherwise they very quickly just dictate that Python cannot be 
used at all.


Cheers,
Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/V2JKVPEDQPJJHF5W4MJRER5FBH3I4WLU/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 632: Deprecate distutils module

2020-09-07 Thread Stefan Krah
On Mon, Sep 07, 2020 at 11:43:41AM +0100, Steve Dower wrote:
> Rest assured, I am very aware of air-gapped and limited network systems, as
> well as corporate policies and processes. Having distutils in the standard
> library does not help with any of these.

Of course it helps.  You can develop extensions without any third party
packages or install them.

Same situation if you are on mobile Internet or in a cafe without Internet
and you want to try something out.


Or if you moved and you don't have cable Internet yet.  Or if you are in
a country where there is no cable Internet.


Air-gapped systems were just an illustration of the problem. I did not
anticipate that people would take it as the centerpiece of my arguments.


Stefan Krah

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/FNRIPAE4SN33STYR2OUHOKFKPUPOSJMU/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 632: Deprecate distutils module

2020-09-07 Thread Steve Dower

On 07Sep2020 1424, Stefan Krah wrote:

On Mon, Sep 07, 2020 at 11:43:41AM +0100, Steve Dower wrote:

Rest assured, I am very aware of air-gapped and limited network systems, as
well as corporate policies and processes. Having distutils in the standard
library does not help with any of these.


Of course it helps.  You can develop extensions without any third party
packages or install them.

Same situation if you are on mobile Internet or in a cafe without Internet
and you want to try something out.


Or if you moved and you don't have cable Internet yet.  Or if you are in
a country where there is no cable Internet.


Air-gapped systems were just an illustration of the problem. I did not
anticipate that people would take it as the centerpiece of my arguments.


Sorry, I didn't mean to imply that - I used "limited network" to capture 
the rest. I make exactly the same arguments at work from your side for 
many other situations, so if you'd like I can give you an even more 
exhaustive list of scenarios where we can't rely on highly available 
internet :)


And yet despite that, I think in this case you're clutching at straws. 
Sure, you can develop extensions without any third party packages, but 
you can't develop them with *supported* first party packages.


Unless you're offering to take over distutils maintenance? In which 
case, I'll happily withdraw the PEP :)


Cheers,
Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2HBDAXQA6HQF4QKSKAVUZLXZXSZ5SU75/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 632: Deprecate distutils module

2020-09-07 Thread Pradyun Gedam
On Sat, Sep 5, 2020 at 5:14 PM Edwin Zimmerman 
wrote:

> The point remains that these situations exist where it is simply
> impossible to run 'pip install xyz' due to network restrictions.  I know
> this firsthand because I have written software for enforcing total internet
> blocks.
>

I'm not sure I understand how "can't hit the network" => "can't use pip".
pip doesn't NEED to hit the network to be functional. The following works
without hitting the network. It's even "fairly fast" if you built wheels
already. :)

$ pip install --no-index --find-links path/to/source/tarballs/and/wheels
my-amazing-super-important-package

--
Pradyun
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IAX54A4FBRTKARSPE2FNDVSPVR3XOVHN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 632: Deprecate distutils module

2020-09-07 Thread Stefan Krah
On Mon, Sep 07, 2020 at 02:40:40PM +0100, Steve Dower wrote:
> > Air-gapped systems were just an illustration of the problem. I did not
> > anticipate that people would take it as the centerpiece of my arguments.
> 
> Sorry, I didn't mean to imply that - I used "limited network" to capture the
> rest. I make exactly the same arguments at work from your side for many
> other situations, so if you'd like I can give you an even more exhaustive
> list of scenarios where we can't rely on highly available internet :)
> 
> And yet despite that, I think in this case you're clutching at straws. Sure,
> you can develop extensions without any third party packages, but you can't
> develop them with *supported* first party packages.

I'm under the impression that distutils has effectively been frozen for
the last decade, except for the substantial improvements you made for the
MSVC part.

For Unix, no one has addressed e.g. C++ support. The underlying reason
has always been that we cannot change anything lest it breaks someone's
package.


So I have some trouble understanding why we have exercised that kind
of restraint (I might have committed a very small C++ patch otherwise)
if we can now break everything at once.


> Unless you're offering to take over distutils maintenance? In which case,
> I'll happily withdraw the PEP :)

No, thanks. :)

I've looked at the log, most maintenance patches are from a variety of
active core devs (this includes, of course, the MSVC patches from you).

Will they submit patches to setuptools from now on?


Stefan Krah

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2V3YE4LCJCTHHCRHPK2XYLPZMYVXQCCG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: pty2

2020-09-07 Thread Terry Reedy

On 9/6/2020 10:38 PM, Soumendra Ganguly wrote:

Hello.
I am currently using a tiling window manager ( i3wm ). While
using pty.spawn(), resizing xterm's X window also resizes the
underlying terminal size; as a result, output of commands such as
ls(1) become incorrectly laid out, making them very hard to read.

Further, I have noticed that the pty library has several long-standing
issues (such as bpo-26228).

I have made several improvements to the pty and tty libraries. I
propose that we create a new library "pty2" (
https://github.com/8vasu/pypty2 ) while keeping "pty" for backward
compatibility, because there are several unmerged conflicting PRs
related to these issues.


The problem is that pty has no active maintainer to make decisions. 
Proposing a duplicate module will not solve that.



--
Terry Jan Reedy
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/37WAPSDMRHHY66IR2POQCCBLEEL6XAWN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 632: Deprecate distutils module

2020-09-07 Thread Barry


> On 7 Sep 2020, at 14:28, Stefan Krah  wrote:
> 
> On Mon, Sep 07, 2020 at 11:43:41AM +0100, Steve Dower wrote:
>> Rest assured, I am very aware of air-gapped and limited network systems, as
>> well as corporate policies and processes. Having distutils in the standard
>> library does not help with any of these.
> 
> Of course it helps.  You can develop extensions without any third party
> packages or install them.

But you do not need distutils to write python extensions right?

Barry




> 
> Same situation if you are on mobile Internet or in a cafe without Internet
> and you want to try something out.
> 
> 
> Or if you moved and you don't have cable Internet yet.  Or if you are in
> a country where there is no cable Internet.
> 
> 
> Air-gapped systems were just an illustration of the problem. I did not
> anticipate that people would take it as the centerpiece of my arguments.
> 
> 
> Stefan Krah
> 
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/[email protected]/message/FNRIPAE4SN33STYR2OUHOKFKPUPOSJMU/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/J2MVXV3DHJ35OFDIH5P7YMTDMVKWXCND/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 632: Deprecate distutils module

2020-09-07 Thread Jim J. Jewett
Emily Bowman wrote:
> If you can update to a breaking Python version, but aren't allowed one
> single point version of an external module, you have a process problem.

Agreed.  Does it surprise you to know that many large organizations have a 
process problem?
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/MBQJQTENT5HIPUJRWZEBLB5AZ4VBR7AZ/
Code of Conduct: http://python.org/psf/codeofconduct/