[Distutils] Fwd: Re: PEP 517 again

[xoviat]

>  I *do* care about telling backends we don't want "different
results from those that would be obtained by exporting an sdist
first".

I completely agree with this statement, but I don't believe that it can or
should be accomplished with this parameter. Let me just quote the process
that I proposed:


> Proposed process:
- Frontend copies source tree to temporary directory
- Frontend invokes build-sdist to build an sdist
- Frontend extracts sdist to new temporary directory
- Frontend reloads backend from sdist directory and invokes build-wheel

This process makes the most sense to me because there will be a limited
number of frontends AND the frontends will enforce correctness. I don't
think we should be too cautious about burdening the frontends will more
responsibility, because it will only be implemented once or twice. And to
clarify, the build_sdist is required.

2017-08-24 9:51 GMT-05:00 Paul Moore <p.f.moore at gmail.com>:

> On 24 August 2017 at 15:26, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> > I particularly want to hear from Nick, Daniel, Donald and Paul on their
> > understanding of the build_directory parameter. There were reasons why it
> > got added, and even if those reasons no longer seem so convincing to me,
> > it's only going to be removed again if we can reach a consensus on
> working
> > without it.
>
> OK. I've not had much time recently (RL issues) and so my apologies if
> I've forgotten context here. But my feelings are:
>
> 1. I've been pretty much persuaded that including features in the
> interface to defend against badly written backends is not worthwhile.
> (I still worry that it may be hard to provide good error reporting for
> backend errors, but that's a lesser issue).
> 2. I'm not completely clear on how pip's implementation will work - I
> think the intention is to always build a sdist and build a wheel from
> that, unless the backend reports it can't build a sdist, in which case
> we ask it to build a wheel directly.
> 3. I'm not particularly comfortable with backends saying that they can
> only produce a wheel and not a sdist, but accept that might have to be
> a reality in some cases. I would be *really* bothered by a backend
> that wasn't even willing to accept that sdist->wheel and direct wheel
> builds should be equivalent - but I don't know if that's something
> that is likely to happen (we can of course state that expectation in
> the PEP). The PEP seems to think this is possible, though[1] (see my
> next point).
> 4. The point of all this is that the definition of build_directory
> says "If build_directory is None, the backend may do an 'in place'
> build which modifies the source directory and may produce different
> results from those that would be obtained by exporting an sdist
> first". That's the bit that bothers me a lot - if we lose
> build_directory, we lose the option for pip to request that a backend
> produce a wheel "equivalent to producing an sdist first". And that
> capability is something I think pip should require[2]. I don't
> particularly care who specifies the actual directory (as per your
> comment, I thought someone else wanted this, for caching or something)
> but I *do* care about telling backends we don't want "different
> results from those that would be obtained by exporting an sdist
> first".
>
> Paul
>
> [1] The only example I can think of is flit where the user doesn't
> have git installed. But then I'd expect that a wheel generated
> directly in that case would be the same as if the user installed git
> then did sdist->wheel, so I'd still consider that to be maintaining
> the invariant I care about.
> [2] I'm not likely to be the one implementing pip's PEP 517 support,
> so I could be overridden on this, of course.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170824/96e707bc/attachment-0001.html>