Re: [Distutils] A possible refactor/streamlining of PEP 517

On Fri, Jul 7, 2017 at 8:27 PM, Nick Coghlan wrote: > The latest round of discussions have been enlightening, as they have > allowed us to articulate that from pip's point of view, the key > requirement is to be able to tell a backend not to include anything > that wouldn't be included when buildi

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Fri, Jul 14, 2017, at 11:18 AM, Nathaniel Smith wrote: > OTOH this whole 11th hour discussion of forcing every build system to > have in-tree and out-of-tree build support is solving some other > problem. It is not my intention to force build systems to support either of these. - Where build

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Fri, Jul 14, 2017 at 3:32 AM, Thomas Kluyver wrote: > it appears to be non-negotiable that there is some > way of building without affecting the source directory, so whatever the > interface is, we need some way to do this. But this is confusing the means with the ends. Obviously no cares abou

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 14 July 2017 at 20:18, Nathaniel Smith wrote: > On Fri, Jul 7, 2017 at 8:27 PM, Nick Coghlan wrote: > Some possible problems that I've seen mentioned in the thread include: > > - pip doesn't trust build systems to properly support incremental > builds, so it wants to force it to throw away the

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 14 July 2017 at 11:32, Thomas Kluyver wrote: > On Fri, Jul 14, 2017, at 11:18 AM, Nathaniel Smith wrote: >> OTOH this whole 11th hour discussion of forcing every build system to >> have in-tree and out-of-tree build support is solving some other >> problem. > > It is not my intention to force b

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 14 July 2017 at 20:59, Nathaniel Smith wrote: > On Fri, Jul 14, 2017 at 3:32 AM, Thomas Kluyver wrote: >> it appears to be non-negotiable that there is some >> way of building without affecting the source directory, so whatever the >> interface is, we need some way to do this. > > But this is

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 14 July 2017 at 21:23, Nick Coghlan wrote: > The design that PEP 517 has settled on is to say that since both > in-place and out-of-tree builds are reasonable things for a frontend > to request, the *API* will allow frontends to request either an > in-place build ("build_directory is None" or >

[Distutils] PEP 420 on python2

Hi everyone, I m very new around here, I just wanted to let you know that while writing a custom importer for py2 and py3, I ended up backporting some python3 libimport code to python2. The code is over there : https://github.com/asmodehn/filefinder2 This way I now support importing packages with

Re: [Distutils] PEP 420 on python2

On 14 July 2017 at 12:12, Asmodehn Shade wrote: > Hi everyone, > > I m very new around here, I just wanted to let you know that while writing a > custom importer for py2 and py3, I ended up backporting some python3 > libimport code to python2. > > The code is over there : https://github.com/asmode

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Fri, Jul 14, 2017, at 11:59 AM, Nathaniel Smith wrote: > What are the advantages of this design, as compared to the > fallback of doing unconditional copytree (like pip does now and may > well continue doing for years to come regardless of what we say here), I don't think pip currently does cop

Re: [Distutils] A possible refactor/streamlining of PEP 517

The PEP process is awful. Sorry. Thank you for helping to make this happen. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] A possible refactor/streamlining of PEP 517

> On Jul 14, 2017, at 9:46 AM, Thomas Kluyver wrote: > > On Fri, Jul 14, 2017, at 11:59 AM, Nathaniel Smith wrote: >> What are the advantages of this design, as compared to the >> fallback of doing unconditional copytree (like pip does now and may >> well continue doing for years to come regardl

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Fri, Jul 14, 2017 at 4:00 AM, Nick Coghlan wrote: > On 14 July 2017 at 20:18, Nathaniel Smith wrote: >> On Fri, Jul 7, 2017 at 8:27 PM, Nick Coghlan wrote: >> Some possible problems that I've seen mentioned in the thread include: >> >> - pip doesn't trust build systems to properly support inc

Re: [Distutils] A possible refactor/streamlining of PEP 517

> On Jul 14, 2017, at 2:24 PM, Nathaniel Smith wrote: > > On Fri, Jul 14, 2017 at 4:00 AM, Nick Coghlan > wrote: >> On 14 July 2017 at 20:18, Nathaniel Smith wrote: >>> On Fri, Jul 7, 2017 at 8:27 PM, Nick Coghlan wrote: >>> Some possible problems that I've seen men

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 14 July 2017 at 19:24, Nathaniel Smith wrote: >>> - pip doesn't trust build systems to properly support incremental >>> builds, so it wants to force it to throw away the build artifacts >>> after every build >> >> It's less that, and more pip wanting to ensure that the default >> publisher expe

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 14 July 2017 at 21:23, Donald Stufft wrote: > * I think it is a requirement that any PEP that proposes a mechanism for > removing ``setup.py`` supports sdist and wheel building in it’s interface. > Otherwise it sends a message that either one is an optional part of Python > packaging, which is

Re: [Distutils] A possible refactor/streamlining of PEP 517

I proposed the build directory parameter because the copytree hook made no sense to me. It is not a perfect substitute but perhaps a configurable build directory is nice on its own without having to satisfy all older arguments in favor of copytree. I think true in-place builds are the oddball (for

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Sat, Jul 15, 2017 at 9:31 AM, Daniel Holth wrote: > I proposed the build directory parameter because the copytree hook made no > sense to me. It is not a perfect substitute but perhaps a configurable > build directory is nice on its own without having to satisfy all older > arguments in favor

Re: [Distutils] PEP 420 on python2

Hi, I had a look at libimport2, but I found out it was a bit buggy and I couldnt extend it as I had hoped. The custom importer I m working on basically extends PathFinder, FileFinder and SourceFileLoader, and I wanted to have the same implementation for py2 and py3, so I ended up reimplementing t

[Distutils] Including soabi tag in --user path?

Hi all, A user on the pywavelets mailing list seems to have gotten themselves into a mess: AFAICT they did 'pip install --user pywavelets' using a ucs4 python, and then started a ucs2 python and tried to import it, which of course failed because these two python builds have incompatible ABIs, even

Re: [Distutils] Including soabi tag in --user path?

On Jul 15, 2017, at 00:22, Nathaniel Smith wrote: > A user on the pywavelets mailing list seems to have gotten themselves > into a mess: AFAICT they did 'pip install --user pywavelets' using a > ucs4 python, and then started a ucs2 python and tried to import it, > which of course failed because th

Re: [Distutils] Including soabi tag in --user path?

On Fri, Jul 14, 2017 at 9:37 PM, Ned Deily wrote: > On Jul 15, 2017, at 00:22, Nathaniel Smith wrote: >> A user on the pywavelets mailing list seems to have gotten themselves >> into a mess: AFAICT they did 'pip install --user pywavelets' using a >> ucs4 python, and then started a ucs2 python and

Re: [Distutils] Including soabi tag in --user path?

On Jul 15, 2017, at 00:41, Nathaniel Smith wrote: > > On Fri, Jul 14, 2017 at 9:37 PM, Ned Deily wrote: >> On Jul 15, 2017, at 00:22, Nathaniel Smith wrote: >>> A user on the pywavelets mailing list seems to have gotten themselves >>> into a mess: AFAICT they did 'pip install --user pywavelets'

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 15 July 2017 at 07:31, Daniel Holth wrote: > I proposed the build directory parameter because the copytree hook made no > sense to me. It is not a perfect substitute but perhaps a configurable build > directory is nice on its own without having to satisfy all older arguments > in favor of copyt

Re: [Distutils] PEP 420 on python2

On 15 July 2017 at 14:07, Asmodehn Shade wrote: > Hi, > > I had a look at libimport2, but I found out it was a bit buggy and I couldnt > extend it as I had hoped. That's unfortunately entirely plausible, as the downside of importlib co-evolving with the import implementation in the interpreter is

Re: [Distutils] Including soabi tag in --user path?

On Fri, Jul 14, 2017 at 9:48 PM, Ned Deily wrote: > On Jul 15, 2017, at 00:41, Nathaniel Smith wrote: >> >> On Fri, Jul 14, 2017 at 9:37 PM, Ned Deily wrote: >>> On Jul 15, 2017, at 00:22, Nathaniel Smith wrote: A user on the pywavelets mailing list seems to have gotten themselves int

Re: [Distutils] Including soabi tag in --user path?

On 15 July 2017 at 14:41, Nathaniel Smith wrote: >> _psutil_osx.cpython-35m-darwin.so > > Right, but this only helps if you install multiple builds of the same > package on top of each other. Which Debian is able to arrange, so PEP > 3149 solves their problem. But the --user dir is managed by pip,

Re: [Distutils] Including soabi tag in --user path?

On Jul 15, 2017, at 01:51, Nick Coghlan wrote: > Well, sort of - it's not intrinsic to *pip* or *Python* that this > happens, it's an artifact of the fact that even though the > compatibility tagging scheme allows for it, folks don't tend to > publish "multi-SOABI" wheel files (where the 35dm and

Re: [Distutils] Including soabi tag in --user path?

On 15 July 2017 at 16:00, Ned Deily wrote: > On Jul 15, 2017, at 01:51, Nick Coghlan wrote: >> Rather than attempting to change how site-packages works (which >> wouldn't help until 3.7+ anyway), the main missing piece in the status >> quo is the equivalent of a "mergewheel" operation that create