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] Reproducible builds (Sdist)

* Matthias Bussonnier , 2017-09-29, 11:16: I'm interested in the reproducible build of an _sdist_. That is to say the process of going from a given commit to the corresponding TGZ file. It is my understanding that setting SOURCE_DATE_EPOCH (SDE for short) should

Re: [Distutils] Reproducible builds (Sdist)

> Does it make sense to add a new optional metadata field to store the > value of SOURCE_DATE_EPOCH if it's set when a distribution is built? I > guess it could cause problems if unpacking & repacking a tarball means > that its metadata is no longer accurate, though. That make sens – and that

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] Reproducible builds (Sdist)

On Fri, Sep 29, 2017, at 07:16 PM, Matthias Bussonnier wrote: > Second; is there a convention to store the SDE value ? I don't seem to > be able to find one. It is nice to have reproducible build; but if > it's a pain for reproducers to find the SDE value that highly decrease > the value of SDE

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

[Distutils] Reproducible builds (Sdist)

Hello there, I'm going to ask questions about Reproducible Builds, a previous thread have been started in March[1], but does not cover some of the questions I have. In particular I'm interested in the reproducible build of an _sdist_. That is to say the process of going from a given commit to

Re: [Distutils] PEP 517 - is it ready?

Spelling mistake fixed! And a huge thank you to everyone for trudging forward with this and reaching this point. I think this will be a real boon for the community. On Fri, 29 Sep 2017 at 01:08 Ben Finney wrote: > Nick Coghlan writes: > > > I've

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] PEP 517 - is it ready?

Nick Coghlan writes: > I've heard back off-list from the folks I was waiting to hear from, > and I'm very happy to say that I'm provisionally accepting PEP 517, as > defined in > https://www.pypa.io/en/latest/specifications/#provisional-acceptance Good news. You might want

Re: [Distutils] PEP 517 - is it ready?

On 29 September 2017 at 07:38, Nick Coghlan wrote: > Thank you Thomas and Nathanial for your persistence in working through > all the feedback received on the proposal, and thus enabling a > significant step forward for the overall Python packaging ecosystem :) Yay! This has

Re: [Distutils] PEP 517 - is it ready?

On 11 September 2017 at 20:36, Thomas Kluyver wrote: > Discussion on PEP 517 seems to have settled down, and I believe that > Nick said he was about ready to accept it. Is everyone involved > satisfied with the current state? Or is there anything else you think > should be

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