> On May 10, 2016, at 9:27 PM, Robert Collins <robe...@robertcollins.net> wrote: > > On 11 May 2016 at 12:39, Brett Cannon <br...@python.org> wrote: >> Donald, Nathaniel, and I have finished our proposed PEP for specifying a >> projects' build dependencies. The PEP is being kept at >> https://github.com/brettcannon/build-deps-pep, so if you find spelling >> mistakes and grammatical errors please feel free to send a PR to fix them. >> >> The only open issue in the PEP at the moment is the bikeshedding topic of >> what to name the sub-section containing the requirements: `[package.build]` >> or `[package.build-system]` (we couldn't reach consensus among the three of >> us on this). Otherwise the three of us are rather happy with the way the PEP >> has turned out and look forward to this being the first step towards >> allowing projects to customize their build process better! > > I find calling this build dependencies confusing, but perhaps thats just me. > > Right now the work flow is this: > > unpack tarball > run setup.py egg-info > introspect that for dependencies > download and install such dependencies (recursively) [ in future, it > would resolve ] > run setup.py install || setup.py wheel > install > > 1) What would pip do when it encounters one of these files? > unpack tarball > introspect and prepare an isolated environment with the specified dependencies > run setup.py egg_info > download and install such runtime dependencies (recursively) [ in > future, it would resolve ] > run setup.py install || setup.py wheel > install > > ?
Yes
>
> Right now setup.py dependencies are turing complete, and its a useful
> escape valve - this design seems to have no provision for that
> (previous designs we've had here have had that). If the declared
> dependencies are merely those needed to be able to invoke the build
> system, rather than those needed to be able to successfully build, it
> would preserve that escape valve.
I think the way this will eventually end up going, is that when we get to the
point of adding that next PEP that allows us to swap out setup.py for a totally
different interface, is that we'll add something like bootstrap_requires or
something, and do something like "If package.build.requires exists, we'll use
that for build dependencies, else we'll invoke some API in the ABS to get
them".
Thus this lets us do the simple thing now, and in the future we can layer on
additional things in a backwards compatabile way that *also* keeps the simple
case simple and allows the advanced case to happen.
>
> 2) what do we expect setuptools to do here? Is it reasonable to
> introspect this file and union it with setup_requires?
I think setuptools should just ignore this file when invoking setup.py directly
(maybe raise an error if something doesn’t exist) because I think the common
pattern is going to be using real, top level imports of the stuff depended on
here so it won’t have a chance to setup_requires them prior to executing.
I think that easy_install should behave similarly to pip though.
>
> 3) Why does this specify ' what dependencies are required to go from
> source checkout to built wheel' ? - build systems also run tests,
> generate docs and man pages, produce other artifacts. Perhaps making
> either the target more specific (wheel_requires = ...) or the
> description less specific ('dependencies required to invoke the build
> system') would be good.
I think the description just wasn't fully thought out. I believe that
"dependencies to invoke the build system" is closer to what I've been viewing
this as (particularly since with setup.py the way it is, it's hard to
differentiate between the different "roles" of why you might be invoking
setup.py).
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
