On 2 September 2016 at 13:30, Antony Lee <anntzer....@gmail.com> wrote:
>> Similarly, it wouldn't astonish me if we eventually see an emergent
>> practice of people writing pyproject.toml.in files for complex
>> projects, in order to move some particular forms of complexity away
>> from build time and towards development time - this would be a similar
>> practice to folks using autoconf to generate a project's C Makefile.
>
> This actually formulates much better than I could have done the reasons why
> I dislike PEP518: it's only going to lead to reinventing the wheel (AKA
> autoconf, which is a pretty big wheel to reinvent).
Unlike autoconf, we don't need to support building arbitrary C/C++
projects - rather, we just want people to have a backend independent
way to tell Python-centric toolchains how to invoke their *existing*
build system (whether that's autoconf/make, CMake, Scons, waf, Meson,
yotta, etc).
It's the current *lack* of that ability to readily integrate with
existing build tools (whether written in Python or not) that prompts
people to reinvent the world.
Defining and support PEP 518 means that a possible future workflow for
autoconf using projects would be something like:
$ ./configure && make pyproject.toml && pip install -e .
In that kind of scenario, the "tell Python tools how to build our
Python bindings" file becomes just another output of a project's
existing build system, which is entirely feasible with a well
documented static format, but impractical with the current
underspecified and underdocumented setup.py based approach.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
