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
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
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
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
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
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
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
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
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
> *
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
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
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
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
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
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
>
> 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
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
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
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
> 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
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
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
22 matches
Mail list logo