[Distutils] PEP 517 again

[Phil Austin]

On 2017-08-29 01:20, Paul Moore wrote:
> On 29 August 2017 at 01:13, Chris Barker <chris.barker at noaa.gov> wrote:
>> On Mon, Aug 28, 2017 at 12:50 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>>
>>> Me too. At the moment, I only expect two backends of any substance -
>>> your flit backend and xoviat's setuptools one. But I only know of one
>>> frontend, namely pip - and talk of projects like tox or twine acting
>>> as frontends never seems to get any traction.

scikit-build also expressed some interest:

https://www.mail-archive.com/distutils-sig@python.org/msg26553.html

although I don't see the pull request.



>>
>>
>> If the build API is clean and supported enough, I can see conda using it.
>>
>> just sayin'
> 
> Thanks - that's really good to know. So *is* the build API clean
> enough for you? Specifically:
> 
> 1. build_sdist can be missing, or can report back (somehow) that it
> failed to produce a sdist, and you should fall back to build_wheel.
> 2. build_wheel must always succeed and must always exist.
> 3. All hooks must be run in a separate subprocess
> 
> There's also error handling, which I don't recall the details of, but
> I think boils down to the backend code can write what it likes to
> stdout/stderr and may raise an exception indicating "something blew
> up".
> 
> Those are basically the key points at the moment. Add to that, does
> conda mind if build_wheel might result in a different wheel than
> build_sdist->build_wheel would produce?
> 

conda-build doesn't produce or consume wheels.  It works by creating a 
clean conda environment and running a shell script to install the python 
package into that environment (including its own versions of /usr/lib 
/usr/etc /usr/bin  /urs/include /sbin -- which is why it can cope with 
non-python packages like g++, julia, R, git etc.).   All files produced 
by the install script are then put into a tar file, which is conda's 
version of a wheel.