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