[Distutils] PEP 517 again

[Chris Barker]

On Sun, Aug 27, 2017 at 2:59 AM, Paul Moore <p.f.moore at 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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170828/95bb64eb/attachment.html>