Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Thomas Kluyver
On Sat, May 20, 2017, at 07:54 AM, Nick Coghlan wrote: > * on platforms with 8-bit standard streams (e.g. Linux, Mac OS X), > build systems SHOULD emit UTF-8 encoded output > * on platforms with 16-bit standard streams (e.g. Windows), build > systems SHOULD emit UTF-16-LE encoded output I'm quite

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Nick Coghlan
On 20 May 2017 at 01:16, Thomas Kluyver wrote: > On Fri, May 19, 2017, at 03:41 PM, Paul Moore wrote: >> Can we specify what encoding the informational text must be written >> in? > > Sure, that makes sense. What about: > > All hooks are run with working directory set to the

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Paul Moore
On 20 May 2017 at 09:03, Thomas Kluyver wrote: > On Sat, May 20, 2017, at 07:54 AM, Nick Coghlan wrote: >> * on platforms with 8-bit standard streams (e.g. Linux, Mac OS X), >> build systems SHOULD emit UTF-8 encoded output >> * on platforms with 16-bit standard streams

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Nick Coghlan
On 20 May 2017 at 00:18, Thomas Kluyver wrote: > Hi, > > I'd like to make another push for PEP 517, which would make it possible > to build wheels from a source tree with other build tools, without > needing setup.py. > > https://www.python.org/dev/peps/pep-0517/ > > Last

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Steve Dower
On 20May2017 0820, Nick Coghlan wrote: Good point regarding the fact that the Windows 16-bit APIs only come into play for interactive sessions (even in 3.6+), while for PEP 517 we're specifically interested in the 8-bit pipes used to communicate with build subprocesses launched by an

[Distutils] Finally making distlib handle spaces

2017-05-20 Thread Radon Rosborough
Hi all, Since at least 2011, virtualenv has not supported spaces in paths. This has bitten many people, including myself, and caused numerous issues over the years [1] [2] [3] [4] [5] [6] [7]. However, as was discussed in [8], the issue lies not with virtualenv but with distlib, via pip. It

[Distutils] Introducing PyPIContents

2017-05-20 Thread Luis Alejandro Martínez Faneyth
Hi everyone, I'm new to this list but I've been reading some threads in the archive. Around february, an idea about indexing modules from PyPI packages was brought up. I've been working on something similar for quite a while. PyPIContents is an index of PyPI packages that lists its modules and

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Nick Coghlan
Good point regarding the fact that the Windows 16-bit APIs only come into play for interactive sessions (even in 3.6+), while for PEP 517 we're specifically interested in the 8-bit pipes used to communicate with build subprocesses launched by an installation tool. On 20 May 2017 at 19:11, Paul

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Thomas Kluyver
On Sat, May 20, 2017, at 05:36 PM, Steve Dower wrote: > I'll probably read the PEP closely and see that this is entirely > incorrect, but if it's right: > > * encoding for text between the build UI and build tool should just be > specified once for all platforms (i.e. use UTF-8). +1 > *

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Brett Cannon
On Fri, May 19, 2017, 09:20 Thomas Kluyver, wrote: > On Fri, May 19, 2017, at 05:17 PM, Paul Moore wrote: > > On 19 May 2017 at 16:53, Daniel Holth wrote: > > > Congrats on getting 518 in. > > > > Agreed, by the way. That's a big step! > > Thanks both. It

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Steve Dower
On 20May2017 1011, Thomas Kluyver wrote: On Sat, May 20, 2017, at 05:36 PM, Steve Dower wrote: In general, since most subprocesses (at least on Windows) do not have customizable encodings, the tool that launches them needs to know what the encoding is. Since we don't live in a Python 3.6 world

Re: [Distutils] Introducing PyPIContents

2017-05-20 Thread Thomas Kluyver
Hi Luis, Awesome, thanks for this :-). It was me posting before about indexing PyPI. I'm intrigued: how do you keep it up to date using Travis? When I looked into this, I was pretty sure you need to download every package to index it. Do you have some way to only download the new releases? Or is

Re: [Distutils] Introducing PyPIContents

2017-05-20 Thread Luis Alejandro Martínez Faneyth
Hi Thomas, 2017-05-20 13:23 GMT-04:00 Thomas Kluyver : > Hi Luis, > > Awesome, thanks for this :-). It was me posting before about indexing PyPI. > > I'm intrigued: how do you keep it up to date using Travis? When I looked > into this, I was pretty sure you need to download

Re: [Distutils] Introducing PyPIContents

2017-05-20 Thread Thomas Kluyver
On Sat, May 20, 2017, at 07:29 PM, Luis Alejandro Martínez Faneyth wrote:> It supports ['.whl', '.egg', '.zip', '.tgz', '.tar.gz', '.tar.bz2'] > formats, and it extracts the data using any available. Nice! If there are multiple of those formats present, does it get the data from just one? Or does

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Paul Moore
On 20 May 2017 at 17:36, Steve Dower wrote: > In general, since most subprocesses (at least on Windows) do not have > customizable encodings, the tool that launches them needs to know what the > encoding is. Since we don't live in a Python 3.6 world quite yet, that means >

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Donald Stufft
> On May 20, 2017, at 4:05 PM, Paul Moore wrote: > > I'm a little concerned if we're going to end up with a proposal that > means that distutils is in violation of the spec unless this issue is > fixed. I'm not sure if that's where we're headed, but I wanted to be > clear

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Nick Coghlan
On 21 May 2017 at 02:36, Steve Dower wrote: > On 20May2017 0820, Nick Coghlan wrote: >> >> Good point regarding the fact that the Windows 16-bit APIs only come >> into play for interactive sessions (even in 3.6+), while for PEP 517 >> we're specifically interested in the

Re: [Distutils] Finally making distlib handle spaces

2017-05-20 Thread Paul Moore
On 20 May 2017 at 15:45, Radon Rosborough wrote: > === > Justifications and counterarguments > === [...] While you make a good case countering the issues you quote, I think there's an important issue you

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Paul Moore
On 20 May 2017 at 19:36, Steve Dower wrote: > >> - As a lazy developer, I don't want to read stdout/stderr from a >> subprocess only to spit it back to my own stdout/stderr. I'd much rather >> just launch the subprocess and let it use the same stdout/stderr as my >> build

Re: [Distutils] Finally making distlib handle spaces

2017-05-20 Thread Radon Rosborough
> The current behaviour fails, as you note, but it does so in a > "standard" way - shebang behaviour (and its limitations) is > well-known. I agree with this, but in my opinion the shebang is simply an implementation detail of virtualenv. I would like to quote @JDLH from [1]: "There is nothing

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

2017-05-20 Thread Steve Dower
On 20May2017 1315, Paul Moore wrote: On 20 May 2017 at 17:36, Steve Dower wrote: In general, since most subprocesses (at least on Windows) do not have customizable encodings, the tool that launches them needs to know what the encoding is. Since we don't live in a Python

Re: [Distutils] Finally making distlib handle spaces

2017-05-20 Thread Nick Coghlan
On 21 May 2017 at 07:29, Radon Rosborough wrote: >> The current behaviour fails, as you note, but it does so in a >> "standard" way - shebang behaviour (and its limitations) is >> well-known. > > I agree with this, but in my opinion the shebang is simply an > implementation