[Distutils] Fwd: Re: PEP 517 again

[xoviat]

> 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.

This was the exact process that I proposed, but was told that:


> I agree that the way you want to do packaging is fundamentally
incompatible
with build systems that do not resemble distutils. Perhaps since this is
distutils sig some here are too used to distutils as the only model of how
packaging might work. Beware that, when fighting monsters, you yourself do
not become a monster... for when you gaze long into the abyss. The abyss
gazes also into you.

There seems to be some miscommunication about the actual process being
proposed.


2017-08-24 10:07 GMT-05:00 Nick Coghlan <ncoghlan at gmail.com>:

> On 25 August 2017 at 00:51, Paul Moore <p.f.moore at gmail.com> wrote:
> > 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".
>
> That's a phrasing error in the PEP - ideally, backends should always
> produce consistent results regardless of whether or not the frontend
> builds an sdist first. What that phrasing was attempting to
> acknowledge is that actually ensuring sdist/wheel consistency may have
> some extra requirements (like the git CLI) that may not apply to the
> "just give me a usable wheel, I don't care whether it's publication
> quality or not" case.
>
> The key thing that changed my mind on whether or not we needed to
> include the build_directory parameter from the start was actually the
> NotImplementedError discussion: as soon as we permitted backends to
> raise NotImplementedError for any non-None build_directory setting,
> we'd effectively made supporting the feature optional.
>
> And if supporting the feature's going to be optional anyway, then the
> *whole point* of defining the backend API in Python rather than as a
> CLI was to make it easy for us to add new optional methods later,
> which means we can start without build_directory support, and if we
> find we miss it for some specific reason, then we can add it back as a
> suitably named optional method like "build_wheel_variant" (if the
> use-case is cross-compiling for multiple ABIs without clobbering
> intermediate artifacts), or "build_wheel_with_artifact_cache" (if the
> use case is to allow the frontend to ask that the backend cache
> intermediate values in a particular place).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> 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/d3f81f1a/attachment.html>