Re: [Distutils] PEP 517 again
On Thu, Aug 31, 2017 at 8:57 AM, Paul Moore <p.f.moore@gmail.com> wrote:
As to using pip to build wheels -- there is good reason to do that now, but in s post PEP 517 world, one would call the build system directly to build a wheel-- after all, all pip should be doing is calling the build system anyway.
I disagree - "pip wheel" will still be useful, for example to obtain a wheel from PyPI either by downloading or download & build. Also just to have a unified interface that works regardless of the project backend - if a project switches from setuptools to flit, for example, it would be good if deployment and test scripts didn't have to change.
Isn't that why we have PEP 517? I unified interface to build tools? So I still expect pip wheel to be useful in a post-PEP 517 world. Maybe so -- but all pip should be doing is passing off the job to the back-end. Again, the package manager, well, manages the packages. It shouldn't be concerned with how to build them. -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
On 31 August 2017 at 17:50, Chris Barker <chris.barker@noaa.gov> wrote:
So I still expect pip wheel to be useful in a post-PEP 517 world.
Maybe so -- but all pip should be doing is passing off the job to the back-end.
It also handles locating the appropriate version on PyPI, downloading (including caching the downloads), building via sdist to avoid discrepancies caused by out of date intermediates (yes, the backend should be doing this, let's not open up the "trust the backend" argument again ;-)) Pip also handles *installing* the appropriate backends into the build environment. Certainly "pip install ." is mostly redundant compared to "flit build" (although again, pip provides a unified command line interface - you *could* read pyproject.toml in your deployment script, then install the backend and call the build_wheel hook, but why do that rather than using at least *some* frontend, if not pip?
Again, the package manager, well, manages the packages. It shouldn't be concerned with how to build them.
It isn't - it just manages organising the process of getting the build tools and running them. A simpler competitor to pip that *only* works with wheels and knows nothing about the build process is entirely possible under PEP 517. Indeed such a tool probably doesn't even need PEP 517. But there hasn't been enough demand for such a tool to be built yet, so I doubt people will suddenly be crying out for one when PEP 517 is implemented... Paul
On Thu, Aug 31, 2017 at 12:58 PM Chris Barker <chris.barker@noaa.gov> wrote:
On Thu, Aug 31, 2017 at 8:57 AM, Paul Moore <p.f.moore@gmail.com> wrote:
As to using pip to build wheels -- there is good reason to do that now, but in s post PEP 517 world, one would call the build system directly to build a wheel-- after all, all pip should be doing is calling the build system anyway.
I disagree - "pip wheel" will still be useful, for example to obtain a wheel from PyPI either by downloading or download & build. Also just to have a unified interface that works regardless of the project backend - if a project switches from setuptools to flit, for example, it would be good if deployment and test scripts didn't have to change.
Isn't that why we have PEP 517? I unified interface to build tools?
So I still expect pip wheel to be useful in a post-PEP 517 world.
Maybe so -- but all pip should be doing is passing off the job to the back-end.
Again, the package manager, well, manages the packages. It shouldn't be concerned with how to build them.
pip has always been under appreciated as a build tool. Suppose the next version of pip dropped support for sdists and could only install wheels. Then it would not be a build tool. Very little changes when it switches to supporting sdists from its own setup.py machinery to a more pluggable mechanism. It is a little controversial that it can produce wheels for re-use but the feature is very practical. You could put 'pip wheel' under a different command line tool but why bother.
participants (3)
-
Chris Barker -
Daniel Holth -
Paul Moore