[Distutils] build system abstraction PEP, take #2

[Daniel Holth]

LGTM

Q: Why is build_command a list?
Q: Why isn't the file name venezuelanbeavercheese.json instead of pypa.json?

On Tue, Nov 17, 2015 at 10:06 AM Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Tue, 17 Nov 2015 09:33:56 -0500
> Donald Stufft <donald at stufft.io> wrote:
> >
> > > On Nov 17, 2015, at 9:27 AM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > >
> > >>
> > >> There are a number of separate subcommands that build systems must
> support.
> > >
> > > I wonder how desirable and viable this all is. Desirable, because you
> > > are still asking the build system to appear as setuptools *in some
> way*.
> > > Viable, because pip may some day need to ask more from setuptools and
> > > then third-party build tools will have to adapt and implement said
> > > command-line options, defeating the "abstraction".
> > >
> > > In other words, this PEP seems to be only solving a fraction of the
> > > problem.
> >
> > Can you explain this? I don’t see how it’s true. We need some way for pip
> > to invoke the build system no matter what the build system is. Either
> that
> > API is a Python API or that build system is a CLI based API but either
> way
> > there needs to be some way for that to happen. This PEP chooses (at my
> > request) a defined CLI API because it makes the delineation between build
> > system and pip cleaner.
>
> I may have misunderstood, it seemed to me that "wheel -d" and "develop"
> are simply setuptools commands christened by the PEP.
>
> I tend to think Python APIs are better than CLI APIs, but that probably
> doesn't make a lot of difference.  This assumes of course that
> potential problems are taken care of (such end-of-line conventions and
> character encodings on stdin / stdout :-)).  The one of thing where a
> CLI API is clearly inferior is error report, though...
>
> > The whole point of this PEP is that once we have it, we can’t just
> randomly
> > require more from the build tool than what is in the interface defined in
> > this PEP. If we need more than we have to write a new PEP that extends
> the
> > old interface with a new feature, but at all times it is built on an
> > interface that is standardized via a PEP.
>
> That clears things up, thank you.
>
> Regards
>
> Antoine.
> _______________________________________________
> 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/20151117/1217cee4/attachment-0001.html>