Re: [Distutils] Extracting distutils into setuptools

On 2 October 2017 at 04:55, Donald Stufft wrote: > This isn’t as easy as ensurepip, because ensurepip can wait until the end of > the build process when the entire Python installation has been built. The > same isn’t true for a hypothetical ensuresetuptools module. This is

Re: [Distutils] Extracting distutils into setuptools

On 1 October 2017 at 10:59, Donald Stufft wrote: > > > On Sep 30, 2017, at 3:52 PM, xoviat wrote: > > I don't think CPython needs to bundle all of its build-time dependencies. > That principle doesn't really apply to other Python programs nor most other >

Re: [Distutils] Extracting distutils into setuptools

> On Oct 1, 2017, at 1:53 PM, xoviat wrote: > > After thinking again about that possibilities that we've discussed here, I > realized that a previously proposed alternative would eliminate external > build-time dependencies and allow us to merge setuptools with distutils:

Re: [Distutils] Extracting distutils into setuptools

After thinking again about that possibilities that we've discussed here, I realized that a previously proposed alternative would eliminate external build-time dependencies and allow us to merge setuptools with distutils: an "ensuresetuptools" module. This was proposed by @zooba, but basically the

Re: [Distutils] Extracting distutils into setuptools

It must, or it couldn’t have a build time dependency on distutils :) Top-posted from my Windows phone From: Donald Stufft Sent: Saturday, September 30, 2017 18:15 To: xoviat Cc: Steve Dower; DistUtils mailing list Subject: Re: [Distutils] Extracting distutils into setuptools I think

Re: [Distutils] Extracting distutils into setuptools

I think that the CPython builds a python executable, then uses that built executable to finish the installation. > On Sep 30, 2017, at 9:11 PM, xoviat wrote: > > It would be nice to know whether this information is correct, or whether I > hold an invalid belief. > >

Re: [Distutils] Extracting distutils into setuptools

It would be nice to know whether this information is correct, or whether I hold an invalid belief. 2017-09-30 20:09 GMT-05:00 xoviat : > I have personally not built Python myself (though I've built many an > extension), but what I can say is that I got the idea from Larry

Re: [Distutils] Extracting distutils into setuptools

I have personally not built Python myself (though I've built many an extension), but what I can say is that I got the idea from Larry Hastings. According to him (this if for the Gilectomy fork): "Second, as you hack on the Gilectomy you may break your "python" executable rather badly. This is of

Re: [Distutils] Extracting distutils into setuptools

> On Sep 30, 2017, at 3:52 PM, xoviat wrote: > > I don't think CPython needs to bundle all of its build-time dependencies. > That principle doesn't really apply to other Python programs nor most other > programs in general. AFAIK, CPython already has a build-time dependency

Re: [Distutils] Extracting distutils into setuptools

I don't know whether this will convince anyone otherwise, but at least from my perspective, a build-time dependency is different than a run-time dependency. Assuming that other parts of CPython don't have a run-time dependency on distutils, I don't think CPython needs to bundle all of its

Re: [Distutils] Extracting distutils into setuptools

> On Sep 29, 2017, at 11:21 PM, xoviat wrote: > > I don't think writing shims for distutils is as easy as you make it sound. In > fact, I'd venture to say that it's an intractable problem because of the > difficulty of knowing the number of distutils hacks that are in the

Re: [Distutils] Extracting distutils into setuptools

I don't think writing shims for distutils is as easy as you make it sound. In fact, I'd venture to say that it's an intractable problem because of the difficulty of knowing the number of distutils hacks that are in the wild. 2017-09-29 22:15 GMT-05:00 Donald Stufft : > > > On

Re: [Distutils] Extracting distutils into setuptools

> On Sep 29, 2017, at 5:16 PM, Steve Dower wrote: > > I'm happy enough with this approach, my only problem with it is that I don't > want to be maintaining two versions (the new one that we want people to > change to, and the old one so that people keep working with

Re: [Distutils] Extracting distutils into setuptools

Distutils has many problems as you said, but by direct implication, if setuptools is "intimately tied" to distutils, then setuptools has these problems as well (and I think that it does). > I don’t really have a good answer for that. Probably it’s best to keep setuptools moving along as it’s

Re: [Distutils] Extracting distutils into setuptools

On 29Sep2017 1306, Donald Stufft wrote: There are bits of distutils that are super useful (Steve indicated the compiler support as one of them), and I think a better path forward is to do like we’ve done with the packaging library. Make a compiler package that can handle those bits and

Re: [Distutils] Extracting distutils into setuptools

> On Sep 29, 2017, at 2:31 AM, Nick Coghlan wrote: > > This is one of those changes where the longer term process improvement > benefits are already reasonably clear to the folks involved in > maintaining the software (i.e. we think it will provide a better end > user

Re: [Distutils] Extracting distutils into setuptools

I understand the motivation behind that PEP, but we're not really deprecating distutils, just moving it out into setuptools. The goal should be "not to break anyone's code." 2017-09-29 11:25 GMT-05:00 Brett Cannon : > Actually, you can't remove any module in the stdlib that

Re: [Distutils] Extracting distutils into setuptools

Actually, you can't remove any module in the stdlib that exists in both Python 2.7 and 3.5 until after Python 2.7 is no longer supported: https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5 . On Thu, 28 Sep 2017 at 23:31 Nick Coghlan

Re: [Distutils] Extracting distutils into setuptools

On 29 September 2017 at 07:42, Matthias Klose wrote: > On 27.09.2017 11:37, Nick Coghlan wrote: >> On 27 September 2017 at 12:30, xoviat wrote: In short, I think your proposal is a good one, but how can we allocate manpower? >>> >>> (issue31595 on

Re: [Distutils] Extracting distutils into setuptools

On 27.09.2017 11:37, Nick Coghlan wrote: > On 27 September 2017 at 12:30, xoviat wrote: >>> In short, I think your proposal is a good one, but how can we allocate >>> manpower? >> >> (issue31595 on bugs.python.org) >> >> So what do others think of this? My sense of things is

Re: [Distutils] Extracting distutils into setuptools

> So how do we get there? I would think a fork and merge of both setuptools and distutils would make sense. Preserve the building part of the API, so folks could simply replace the import line an their setup.py files to use the new tool. There's no need to even replace the line in setup.py.

Re: [Distutils] Extracting distutils into setuptools

distutils works fine for its original purpose (building components for the system Python in Linux distros), What does Linux have to with it? In the eagle days, I found it most helpful for Windows, actually. And it's very helpful for OS-X as well. It was also great for pure python

Re: [Distutils] Extracting distutils into setuptools

I meant to include a link, sorry. https://github.com/pfmoore/pylaunch/blob/master/build_zastub.py On 28 September 2017 at 16:11, Paul Moore wrote: > I use distutils to build a C program that embeds Python, for making > standalone launchers. I'm not at all clear how I'd get

Re: [Distutils] Extracting distutils into setuptools

I use distutils to build a C program that embeds Python, for making standalone launchers. I'm not at all clear how I'd get all the information I needed to build a compatible Python (including the "find the appropriate C compiler" dance) manually - I'd probably end up with something that didn't

Re: [Distutils] Extracting distutils into setuptools

Enscons uses parts of distutils to get compiler flags and so on but does not use Extension() to do the actual compiling. There might be a cleaner way to do it that I was not able to find. There could be a cleaner separation between parts of distutils related to how Python itself was compiled and

Re: [Distutils] Extracting distutils into setuptools

On 28 September 2017 at 06:00, xoviat wrote: > That's actually an interesting idea though: for Python 3.7 distutils -> > _distutils (and then setuptools is required for building). For/against? distutils works fine for its original purpose (building components for the system

Re: [Distutils] Extracting distutils into setuptools

On Thu, Sep 28, 2017 at 8:46 AM, xoviat wrote: > No. Setuptools is what projects without a build_backend in pyproject.toml > get. Not distutils. We should make it clear now that the distutils > namespace belongs to setuptools except for when building cpython. > > On Sep 27,

Re: [Distutils] Extracting distutils into setuptools

That's actually an interesting idea though: for Python 3.7 distutils -> _distutils (and then setuptools is required for building). For/against? 2017-09-27 14:46 GMT-05:00 xoviat : > No. Setuptools is what projects without a build_backend in pyproject.toml > get. Not distutils.

Re: [Distutils] Extracting distutils into setuptools

No. Setuptools is what projects without a build_backend in pyproject.toml get. Not distutils. We should make it clear now that the distutils namespace belongs to setuptools except for when building cpython. On Sep 27, 2017 2:33 PM, "Ned Deily" wrote: > On Sep 27, 2017, at

Re: [Distutils] Extracting distutils into setuptools

On Sep 27, 2017, at 13:31, Steve Dower wrote: > setuptools is totally welcome in my book to simply copy the compiler > infrastructure we already have from core and never look back. It really does > need to be maintained separately from CPython, especially on Windows

Re: [Distutils] Extracting distutils into setuptools

/cc @jaraco 2017-09-27 11:34 GMT-05:00 xoviat : > So since PEP 517 is going into setuptools anyway, we can > sys.path.insert(0, NEW_DISTUTILS_LOCATION) and then import distutils in the > interface before setup.py is loaded. Seems simple enough. > > 2017-09-27 11:27 GMT-05:00

Re: [Distutils] Extracting distutils into setuptools

So since PEP 517 is going into setuptools anyway, we can sys.path.insert(0, NEW_DISTUTILS_LOCATION) and then import distutils in the interface before setup.py is loaded. Seems simple enough. 2017-09-27 11:27 GMT-05:00 Nick Coghlan : > On 27 September 2017 at 23:35, Donald

Re: [Distutils] Extracting distutils into setuptools

On 27 September 2017 at 23:35, Donald Stufft wrote: > I suspect this might be difficult, but I haven’t actually tried it. Our > trick (and really setup tools itself relies on this too) is that setuptools > monkey patches distutils at runtime to make distutils into setuptools. It

Re: [Distutils] Extracting distutils into setuptools

On Sep 27, 2017, at 5:37 AM, Nick Coghlan wrote: > > pip's trick of injecting setuptools into a process to change the > behaviour of distutils imports continues to work I suspect this might be difficult, but I haven’t actually tried it. Our trick (and really setup tools

Re: [Distutils] Extracting distutils into setuptools

On 27 September 2017 at 12:30, xoviat wrote: >> In short, I think your proposal is a good one, but how can we allocate >> manpower? > > (issue31595 on bugs.python.org) > > So what do others think of this? My sense of things is that people are open > to the idea, but there isn't

Re: [Distutils] Extracting distutils into setuptools

On Wed, Sep 27, 2017 at 3:30 PM, xoviat wrote: > This was a comment by @zooba (Steve Dower): > > > (FWIW, I think it makes *much* more sense for setuptools to fix this by > simply forking all of distutils and never looking back. But since we don't > live in that world yet, it