[Distutils] PEP 517 - specifying build system in pyproject.toml
Nick Coghlan
ncoghlan at gmail.com
Tue May 23 12:16:42 EDT 2017
On 24 May 2017 at 01:39, Paul Moore <p.f.moore at gmail.com> wrote:
> On 23 May 2017 at 16:20, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Taking that approach of just defining a helper API and expecting build
>> backends to either use it or emulate it gives us some quite attractive
>> properties:
>
> Making the output data part of a structured API (and by implication,
> saying that backends shouldn't be writing to stdout directly at all)
> would definitely improve the situation, IMO. Frankly, it seems likely
> that the only real way we're going to get backend developers to
> consider encodings is by having the "build output" as a string value
> passed back via the API, rather than implied in the fact that backends
> can write to stdout/err. It also squarely places the responsibility
> for dealing with the question of displaying full-range Unicode output
> to the user onto the frontend.
>
> However, it's a relatively big change to the PEP and there's a risk
> that by endlessly reaching for perfection, we miss the chance to get
> the PEP in at all (another lesson we should probably learn from PEP
> 426!)
Yep, and that's also why I want to avoid trying to use it to improve
the encoding handling situation - pip and other tools have to deal
with the current mess regardless, and there's already likely to be
some significant churn in this space as a result of the changes Victor
and I have proposed for Python 3.7.
As a result, I think adding in additional requirements here runs a
significant risk of requiring build backend developers to do
additional work to achieve nominal spec compliance without actually
simplifying anything in practice for frontend developers.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Distutils-SIG
mailing list