[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

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 :

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

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 >

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

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

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

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

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 >

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,

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

[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,

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

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

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

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

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

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

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

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

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.

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