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

On 9/11/2020 12:24 PM, Matthias Klose wrote: On 9/4/20 1:28 PM, Steve Dower wrote: Hi all. setuptools has recently adopted the entire codebase of the distutils module, so that they will be able to make improvements directly without having to rely on patching the standard library. As a result, w

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

On Fri, Sep 11, 2020 at 4:25 AM Matthias Klose wrote: > On 9/4/20 1:28 PM, Steve Dower wrote: > > Hi all. > > > > setuptools has recently adopted the entire codebase of the distutils > module, so > > that they will be able to make improvements directly without having to > rely on > > patching the

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

On 9/4/20 1:28 PM, Steve Dower wrote: > Hi all. > > setuptools has recently adopted the entire codebase of the distutils module, > so > that they will be able to make improvements directly without having to rely on > patching the standard library. As a result, we can now move forward with > offic

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

On Tue, Sep 8, 2020 at 2:27 AM Steve Dower wrote: > On 07Sep2020 1602, Stefan Krah wrote: > > 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

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

On 07Sep2020 1602, Stefan Krah wrote: 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

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

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] Re: PEP 632: Deprecate distutils module

> 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 w

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

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 > re

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

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 su

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

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

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

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 ex

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

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,

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

On Sat, 5 Sep 2020 07:39:10 -0400 Edwin Zimmerman wrote: > On 9/5/2020 3:59 AM, Emily Bowman wrote: > > On Fri, Sep 4, 2020 at 3:11 PM Stefan Krah > > wrote: > > > > > > > > It is not hyperbolic at all. You can get permissions for a certain set > > of modules

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

Then, as Victor said, it will have to be bundled into Python's codebase. On 05.09.2020 11:06, Emily Bowman wrote: On Sat, Sep 5, 2020 at 12:37 AM Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote: As I wrote in https://stackoverflow.com/questions/25337706/setuptools-vs-distu

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

On 9/5/2020 3:59 AM, Emily Bowman wrote: > On Fri, Sep 4, 2020 at 3:11 PM Stefan Krah > wrote: > > > > It is not hyperbolic at all. You can get permissions for a certain set > of modules (the stdlib), but not for PyPI packages. > > Of course the upgrade is n

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

On Sat, Sep 5, 2020 at 12:37 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > As I wrote in > https://stackoverflow.com/questions/25337706/setuptools-vs-distutils-why-is-distutils-still-a-thing/40176290#40176290, > > distutils has a responsibility that setuptools as a 3rd-party ent

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

On Fri, Sep 4, 2020 at 3:11 PM Stefan Krah wrote: > > > It is not hyperbolic at all. You can get permissions for a certain set > of modules (the stdlib), but not for PyPI packages. > > Of course the upgrade is not via the network, that is beside the point. > If you can update to a breaking Pytho

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

As I wrote in https://stackoverflow.com/questions/25337706/setuptools-vs-distutils-why-is-distutils-still-a-thing/40176290#40176290, distutils has a responsibility that setuptools as a 3rd-party entity cannot fulfill -- to set the core standards for addon modules structure and interface and be gu

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

On 9/4/2020 6:00 PM, Stefan Krah wrote: > It is not hyperbolic at all. You can get permissions for a certain set > of modules (the stdlib), but not for PyPI packages. > > Of course the upgrade is not via the network, that is beside the point. Besides upgrades of existing systems, there are also new

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

It is not hyperbolic at all. You can get permissions for a certain set of modules (the stdlib), but not for PyPI packages. Of course the upgrade is not via the network, that is beside the point. On Fri, Sep 04, 2020 at 02:56:07PM -0700, Emily Bowman wrote: > On Fri, Sep 4, 2020 at 10:31 AM St

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

On Fri, Sep 4, 2020 at 10:31 AM Stefan Krah wrote: > > All the time, especially when I'm writing them. I imagine that there's > a huge amount of internal company code that discourages use of pip > installed packages as well. Or has an air-gapped network in the first > place. > That's wildly hyp

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

On Fri, Sep 04, 2020 at 01:10:37PM -0400, Paul Ganssle wrote: > On 9/4/20 12:45 PM, Stefan Krah wrote: > > Since distutils does not change, why remove it? It is a lot of work > > for people with little gain. > > If we don't remove it, we should at least freeze the bug component so > that people c

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

On 9/4/20 12:45 PM, Stefan Krah wrote: > Since distutils does not change, why remove it? It is a lot of work > for people with little gain. If we don't remove it, we should at least freeze the bug component so that people cannot report bugs in distutils. Triaging these bugs alone is a decent amou

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

On 9/4/20 12:22 PM, Paul Moore wrote: > I believe that's correct. My main concern here is that removing > distutils from the stdlib won't have made that problem any better, it > will simply have transferred the responsibility onto the setuptools > maintainers. While I assume that they are comforta

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

I have been using standard distutils for large C extensions without any issues. Since distutils does not change, why remove it? It is a lot of work for people with little gain. I'd really like to build C extensions without downloading an external package. Features like C++ support have not be

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

On Fri, 4 Sep 2020 at 16:53, Fred Drake wrote: > > On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote: > > While I agree with the general suggestion of deprecating distutils as a > > publicly-visible module (in favour of encouraging users to rely on > > setuptools), it seems to me that the argu

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

On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote: > While I agree with the general suggestion of deprecating distutils as a > publicly-visible module (in favour of encouraging users to rely on > setuptools), it seems to me that the argument of facilitating the > development of third-party buil

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

On Fri, 4 Sep 2020 12:28:30 +0100 Steve Dower wrote: > > It will also help > promote the development of alternative build backends, which can now > be supported more easily thanks to PEP 517. While I agree with the general suggestion of deprecating distutils as a publicly-visible module (in favo

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

Hi, Aha, someone proposed the idea :-) I know that Debian removed distutils from Python stdlib (it is a separate package) for a long time. You may mention https://github.com/pypa/distutils/ somewhere in the PEP: "Python Module Distribution Utilities extracted from the Python Standard Library". I