On Sun, Aug 27, 2017 at 2:59 AM, Paul Moore <p.f.moore@gmail.com> wrote:
> Suppose you
> have a frontend like pip that when given a source directory and asked
> to build a wheel, wants to implement that as:
>   - build sdist
>   - unpack sdist
>   - build wheel from unpacked sdist

... I'd like to
point out that in
https://mail.python.org/pipermail/distutils-sig/2017-August/031288.html
I confirmed that I'm basically persuaded now that pip should just
"trust the backend" and use build_wheel directly. So this whole debate
isn't relevant for pip.

Nor should it be for any other system. Before I saw this post I was about to make a point about not contorting ourselves to make things works the same way as pip and setuptools currently work -- pip was kind of hacked together to support setuptools, and setuptools grew kinda-organically from distutils (while also shoehorning in other not-really-building functionality).

So let's make the "new" API clean and adapt the current tools to that.

Specifically, I'm really confused about the sdist concept -- sure, it's a nice idea to have a standard way to create a source distributions, and I can see that tools that, for instance, create uploads for PyPi and the like will want to do that, but I don't see it as an inherent part of building a binary distribution (i.e. wheel), or building and installing a package directly.

So:

If you want a wheel, the build system should be asked to build a wheel.
If you want an sdist, the build system should be asked to build an sdist -- and it can politely decline.

Whether the build system first makes an sdist, and then builds a wheel from that it entirely up to the build system.

Is there any reason to make this more complicated?

We'll need to wait for other
currently-hypothetical frontends like tox or twine which might use the
build_wheel hook, before we'll have any practical experience to
confirm if there's an issue with "return None" as the way for backends
to signal that they weren't able to build a wheel.

Sure -- though I'm with Nathaniel on this one (I think -- kinda hard to keep th threads straight!) getting a NOne can happen for alot of reasons, better to have a more information-rich way to know that something failed.

And isn't "be able to build a wheel" a requirement for ANY supported back-end? In which case, failure to build one is a failure that could have been caused by any number of issues -- shouldn't it simply fail with an Exception -- and the back end will hopefully generate nice exceptions for the common failures?
 
-CHB



--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov