On 10 November 2015 at 15:03, Nathaniel Smith <n...@pobox.com> wrote: > On Sun, Nov 8, 2015 at 5:28 PM, Robert Collins > <robe...@robertcollins.net> wrote: >> +The use of a command line API rather than a Python API is a little >> +contentious. Fundamentally anything can be made to work, and Robert wants to >> +pick something thats sufficiently lowest common denominator that >> +implementation is straight forward on all sides. Picking a CLI for that >> makes >> +sense because all build systems will need a CLI for end users to use anyway. > > I agree that this is not terribly important, and anything can be made > to work. Having pondered it all for a few more weeks though I think > that the "entrypoints-style" interface actually is unambiguously > better, so let me see about making that case. > > What's at stake? > ---------------------- > > Option 1, as in Robert's PEP: > > The build configuration file contains a string like "flit > --dump-build-description" (or whatever), which names a command to run, > and then a protocol for running this command to get information on the > actual build system interface. Build operations are performed by > executing these commands as subprocesses. > > Option 2, my preference: > > The build configuration file contains a string like > "flit:build_system_api" (or whatever) which names a Python object > accessed like > > import flit > flit.build_system_api > > (This is the same syntax used for naming entry points.) Which would > then have attributes and methods describing the actual build system > interface. Build operations are performed by calling these methods.
Option 3 expressed by Donald on IRC (and implied by his 'smaller step' email - hard code the CLI). A compromise position from 'setup.py <what we do there' is to encode the 'setup.py' step in pypa.json, but define the rest as a fixed contract, e.g. with subcommands like wheel, metadata etc. This drops the self describing tool blob and the caching machinery. I plan on using that approach in my next draft. Your point about bugs etc is interesting, but the use of stdin etc in a dedicated Python API also needs to be specified. remember too that pip already has matured code handling CLI's - its not new. The thing thats new is letting what is invoked be parameterised by the source tree. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
