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 <ncogh...@gmail.com> wrote: > > On 20 Mar 2014 23:16, "Brett Cannon" <bcan...@gmail.com> wrote: >> >> >> >> On Thu Mar 20 2014 at 12:51:13 AM, Nick Coghlan <ncogh...@gmail.com> >> wrote: >>> >>> On 20 March 2014 09:54, Vinay Sajip <vinay_sa...@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@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig