On Mon, Jul 3, 2017 at 5:06 PM, Donald Stufft <don...@stufft.io> wrote:
> Adding it on later is a bit tricky because we can’t pass the existing
> metadata into the build_wheel hook then, so they can ensure that they
> generate the same output. The frontend could still of course validate that
> after the fact (which pip likely will) but that removes the chance for the
> project to ensure they work in that case rather than having that case be a
> failure. OTOH I don’t know how likely it is that a project actually does
> something different based on the metadata directory that was passed in other
> than fail if it would do something different.
No, I don't think there'd be any problem with adding it later. In the
current PEP 517 draft, it's already spec'ed as: if a backend has no
prepare_wheel_metadata hook, then build_wheel never gets a metadata
directory; and even if a backend does have a prepare_wheel_metadata
hook, then build_wheel might or might not get a metadata directory. So
if we start out without a prepare_wheel_metadata hook and add it
later, then we'd have:
old frontend + old backend: obviously fine
old frontend + new backend: acts like a new frontend that happened not
to call prepare_wheel_metadata, so that's fine
new frontend + old backend: there's no prepare_wheel_metadata hook, so
it won't try to pass metadata to build_wheel, so that's fine
new frontend + new backend: obviously fine
So adding it now versus later are pretty much equivalent in this respect.
> From my end, I’m happy either with the hook or with the hook Nathaniel has
> spec’d. I think the primary difference is if someone takes a .tar.gz,
> unpacks it, and then runs ``pip install that/dir`` with Nathaniel’s hook we
> would fail if the build_sdist hook didn’t build a sdist (e.g. in the case of
> how I understand flit’s use case.
I think the most important *practical* difference between
current-PEP-517 and my-proposed-PEP-517 isn't about whether the
backend can control what happens when it doesn't support sdist
building, but about whether the backend can control what happens when
it *does* support sdist building.
In my-proposed-PEP-517, there is no prepare_build_files hook, but the
practical effect of this is pretty minimal, because the only
identified use case for prepare_build_files is when building from an
unpacked flit sdist, and in that case, flit's prepare_build_files is
essentially equivalent to a copytree anyway.
OTOH, in current-PEP-517, there is no way for a backend to signal
whether build_sdist will work or not, so if pip sees a
prepare_build_files hook then it *has* to call it, *even if
build_sdist would have worked*. This means that current-PEP-517
supports an interesting practical use case that my-proposed-PEP-517
doesn't: if you're a project like scipy who thinks that in-place
builds are a good idea and has a somewhat adversarial relationship
with the pip devs, you can put something like this in your backend:
if hasattr(os, "symlink"):
def prepare_build_files(tmp_dir):
os.symlink(os.getpwd(), tmp_dir)
and now pip will do in-place builds. (Except on Windows, of course;
Windows users get screwed as usual, but from scipy's perspective
that's pip's fault.)
In my proposal, this doesn't happen because pip will always try
build_sdist before falling back (and also because there is no
prepare_build_files hook, but I'm not opposed to adding that
eventually, I just think the current design is hastily spec'ed and
not-fully-thought-through, as evidenced by the fact that the best use
case I can come up with for it is exactly the one that its advocates
are trying to prevent...).
There's a bit of a complicated linkage here. There are two differences
between my proposal and current-PEP-517: mine has NotImplemented but
not prepare_build_files, and current-PEP-517 has prepare_build_files
but not NotImplemented. In this case, the thing that matters for
preventing in-place-build shenanigans is NotImplemented support. So
there's third possible design, which is to have both NotImplemented
*and* prepare_build_files together. But this doesn't seem very
attractive, because once you have the NotImplemented thing then I
don't know of any practical use cases for prepare_build_fiiles at all.
-n
--
Nathaniel J. Smith -- https://vorpus.org
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
