On Sun, Jun 25, 2017 at 12:26 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 25 June 2017 at 16:58, Nathaniel Smith <n...@pobox.com> wrote:
>> The current spec's solution:
>>
>> - Let's define an exhaustive list of all the reasons you might want to
>> make an sdist:
>> 1) you're a hypothetical future version of pip that has decided to
>> implement some specific build-from-unpacked-source-tree semantics
>> 2) the user has specifically requested an sdist, so if one can't be
>> made then the only thing to do is to fail and pass on some
>> unstructured error log
>> 3) that's it, we've made a list of all possible front-end semantics.
>> - Then define a hook that does (1) and a hook that does (2).
>
> pip doesn't care about making sdists, it only cares about doing out of
> tree wheel builds. It's other tools (e.g. tox) that specifically care
> about making sdists.
>
> So we only have two front-end scanarios that we need to handle:
>
> 1. preparing for an out-of-tree call to build_wheel
> 2. actually building an sdist (e.g. for testing or publication)
Right, the core point of disagreement is:
- I'm not convinced that this list is exhaustive.
- I'm not convinced that we understand the out-of-tree build case,
given that the sdist approach has never been implemented or deployed.
- Even based on our current imperfect understanding of the out-of-tree
build case, I'm not convinced that prepare_build_wheel_files solution
is actually the best solution. (For all the reasons I've said before:
the stated motivation for doing out-of-tree builds is that we don't
trust the build system, but prepare_build_wheel_files forces us to
trust the build system; flit *could* support sdists, the question is
whether it's worth the effort, and I don't believe we really
understand the trade-offs well enough to know the answer to that; in
the flit case copytree() would work just as well as
prepare_build_wheel_files anyway so there's no demonstrated need for
this complexity.)
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. But I feel
like allowing NotImplemented returns + ext_{toolname}_* hooks seems
like it covers all the known cases about as well as the current
design, while being substantially simpler and more future-proof.
-n
--
Nathaniel J. Smith -- https://vorpus.org
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
