[Distutils] waf can be used to compile Python extension modules

[Daniel Holth]

Bento emulates setup.py: https://github.com/cournape/Bento/blob/master/setup.py

It mostly has to implement egg_info and install to be pip compatible.

In the future we'd like them to implement dist_info (generate a
.dist-info directory instead of an .egg-info directory) and wheel; an
sdist would signal that it doesn't implement setup.py install and pip
would always build and then install a wheel. This would be a
relatively simple thing to add to pip.

Once setup.py emulation is working then we could define a Python-level
plugin interface for build systems that might return metadata dicts,
and also provide a setup.py that talks to this plugin interface. A
later version of pip might talk directly to the plugin without
bothering with setup.py.

This strategy does not generally try to eliminate arbitrary code
execution during builds - builds are an inherently arbitrary-code
process. But once the build has happened most installs should work
without arbitrary code execution.

On Fri, Mar 21, 2014 at 6:13 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 20 Mar 2014 23:16, "Brett Cannon" <bcannon at gmail.com> wrote:
>>
>>
>>
>> On Thu Mar 20 2014 at 12:51:13 AM, Nick Coghlan <ncoghlan at gmail.com>
>> wrote:
>>>
>>> On 20 March 2014 09:54, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>>> > Daniel Holth <dholth <at> gmail.com> writes:
>>> >
>>> >> extensions without using distutils. The problem of invoking the
>>> >> compiler has been solved by many build systems and is not just a
>>> >> unique and mysterious distutils feature.
>>> >
>>> > Did someone say it was? Building extensions is something distil does
>>> > too, and
>>> > without using distutils or setuptools.
>>>
>>> Right, the problem is the lack of a standard interface for how the
>>> packaging system is supposed to invoke them - that is, *implementation
>>> independent* docs of what the various setup.py commands are *supposed*
>>> to do.
>>>
>>> The packaging system shouldn't have to care *how* setup.py is
>>> implemented, but at the moment, the behaviour is underspecified to the
>>> point where it's a matter of reverse engineering distutils and/or
>>> implementing what seems necessary and waiting to see if people
>>> complain.
>>
>>
>> What are the plans for the build step in the grand plan of Python
>> packaging? I think previously it has been suggested that once metadata is
>> done and distribution/installation is taken care of the distutils/setuptools
>> building part of all of this will be tackled. Is that still accurate?
>
> That's the priority list for my personal focus, but I certainly wouldn't
> complain if there was momentum behind addressing the build side in parallel,
> rather than in series. Commenting on PEPs is usually easier than writing
> them, and the starting point for the build side is mostly just defining a
> suitable subset of setup.py commands, options, behaviour and invocation
> context that will make up the "fallback legacy interface" a new metabuild
> system would need regardless of any other details.
>
> I just don't have the personal bandwidth to champion such an effort at this
> point in time.
>
> Cheers,
> Nick.
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>