My impressions on reading what is hopefully the current version of the PEP Are there different paths to get to sdist/wheel for example tree -> prepare sdist/wheel files -> build sdist and tree -> build sdist, tree -> build wheel depending on what [pip] decides to do? Should the frontend do both and compare the result to make sure it is the same? I'm not entirely clear on what the prepare hooks should do. The rationalizations interleaved between the descriptions of each hook distract from what the hooks should actually do. Suggested replacement rationalization: "Some people like to build [format]. This hook builds [format]". I will make an effort to implement this for enscons, probably with the most direct tree -> wheel, tree -> sdist hooks and without any optional hooks. Thanks, Daniel On Mon, Jun 26, 2017 at 8:36 AM Nathaniel Smith <njs@pobox.com> wrote:
On Jun 25, 2017 12:46 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 25 June 2017 at 17:41, Nathaniel Smith <njs@pobox.com> wrote:
Maybe you're right and there are exactly 2 front-end use cases and it will turn out that the current PEP addresses them perfectly. I don't have a crystal ball; I'm making an argument from ignorance.
I'm not - we have two concrete potential consumers of the interface (pip and tox, aka "build to use" and "build to test"), and I'm designing the interface to cover their needs (i.e. out-of-tree wheel builds and actual sdists).
If we discover other use cases later, we'll worry about them then (and the easy of doing so is the nicest benefit of defining this as a Python API), but the temptation to design in hyper-flexibility now falls under YAGNI (You Ain' Gonna Need It).
My proposal also covers their needs AFAICT? At least I thought Donald said he thought the would work for pip. And you can't use YAGNI to argue for a more complicated proposal, that's cheating :-).
-n
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig