On 23 May 2017 at 03:38, Steve Dower wrote:
> Okay, I think I get the problem now. We expect backends to let child
> subprocesses just spit out whatever *they* want onto the same stdout/stderr.
>
> I'm really not a fan of forcing front ends to clean up that mess, and so I'd
> still suggest that th
On Mon, May 22, 2017, at 11:36 PM, Steve Dower wrote:
> IMHO, #2 is definitely the right way to go. Yes, the platform specific
> code now has to worry about the encoding, but... the encoding is
> platform specific? So... that seems exactly right? :) Maybe I'm still
> missing something here, but
On 22May2017 1253, Paul Moore wrote:
It seems to me there are 2 schools of thought:
1. There are likely to be fewer front ends than back ends, and so the
front end(s) (basically, pip) should deal with the problem. Also,
backends are more likely to be written by developers who are looking
at very
https://stackoverflow.com/questions/44120045/something-is-breaking-my-package-deployment
has full info on what i am seeing, but it suffices to say:
I use setuptools in my setup.py
I iterate a requirements.txt file to satisfy dependencies.
I publish as sdist to pypi
my package used to work fine a
On 22 May 2017 at 18:38, Steve Dower wrote:
> Okay, I think I get the problem now. We expect backends to let child
> subprocesses just spit out whatever *they* want onto the same stdout/stderr.
s/expect/allow/
The paranoid in me suspects "expect" is also true, though :-)
> I'm really not a fan
On 22May2017 0803, Paul Moore wrote:
On 22 May 2017 at 15:23, Nick Coghlan wrote:
No, that's discussed here:
https://www.python.org/dev/peps/pep-0517/#comparison-to-competing-proposals
Even though PEP 517 defines a Python API for build backends to
implement, it still expects installation tools
On 22 May 2017 at 15:23, Nick Coghlan wrote:
> No, that's discussed here:
> https://www.python.org/dev/peps/pep-0517/#comparison-to-competing-proposals
>
> Even though PEP 517 defines a Python API for build backends to
> implement, it still expects installation tools to wrap a subprocess
> call ar
Hi folks,
The restarted discussion on PEP 517 meant I realised that we hadn't
officially decided between its Python API based approach and PEP 516's
approach of using the backend CLI as the standardised interface (akin
to the current setup.py approach).
My current intention is to reject PEP 516's
On 22 May 2017 at 23:15, Paul Moore wrote:
> On 22 May 2017 at 12:28, Thomas Kluyver wrote:
>> What if it wants to send a character which can't be encoded in the
>> locale encoding? It's quite easy on Windows to end up with a character
>> that you can't encode as cp1252. If the build tool uses .e
On 22 May 2017 at 12:28, Thomas Kluyver wrote:
> What if it wants to send a character which can't be encoded in the
> locale encoding? It's quite easy on Windows to end up with a character
> that you can't encode as cp1252. If the build tool uses .encode(loc_enc,
> 'replace'), then you've lost inf
On 22 May 2017 at 21:28, Thomas Kluyver wrote:
> On Mon, May 22, 2017, at 12:02 PM, Paul Moore wrote:
>> The only reservation I have is that the choice of UTF-8 means that on
>> Windows, build backends pretty much have to explicitly manage tool
>> output (as they are pretty much certain *not* to o
On 22 May 2017 at 21:02, Paul Moore wrote:
> On 22 May 2017 at 11:22, Thomas Kluyver wrote:
>> I have made a PR against the PEP with my best take on the encoding
>> situation:
>> https://github.com/python/peps/pull/264/files
>
> LGTM.
>
> The only reservation I have is that the choice of UTF-8 me
On Mon, May 22, 2017, at 12:02 PM, Paul Moore wrote:
> The only reservation I have is that the choice of UTF-8 means that on
> Windows, build backends pretty much have to explicitly manage tool
> output (as they are pretty much certain *not* to output in UTF-8).
> Build backend writers that aren't
On 22 May 2017 at 11:22, Thomas Kluyver wrote:
> I have made a PR against the PEP with my best take on the encoding
> situation:
> https://github.com/python/peps/pull/264/files
LGTM.
The only reservation I have is that the choice of UTF-8 means that on
Windows, build backends pretty much have to
I have made a PR against the PEP with my best take on the encoding
situation:
https://github.com/python/peps/pull/264/files
On Mon, May 22, 2017, at 11:19 AM, Paul Moore wrote:
> On 22 May 2017 at 10:56, Thomas Kluyver wrote:
> > On Sat, May 20, 2017, at 07:36 PM, Steve Dower wrote:
> >> Require
On 22 May 2017 at 10:56, Thomas Kluyver wrote:
> On Sat, May 20, 2017, at 07:36 PM, Steve Dower wrote:
>> Require that build tools either send UTF-8 to the UI component, or write
>> bytes to a file and call it a build output. I see no benefit in
>> requiring both the build tool and the UI tool to
On Sat, May 20, 2017, at 07:36 PM, Steve Dower wrote:
> Require that build tools either send UTF-8 to the UI component, or write
> bytes to a file and call it a build output. I see no benefit in
> requiring both the build tool and the UI tool to guess what the text
> encoding is.
I'm not propos
17 matches
Mail list logo
