# PEP 517 Backend bootstrapping

**URL:** <https://discuss.python.org/t/pep-517-backend-bootstrapping/789>\
**Category:** Packaging\
**Created:** [January 30, 2019, 1:19am UTC](https://discuss.python.org/t/pep-517-backend-bootstrapping/789 "2019-01-30T01:19:16Z")\
**Posts on this page:** 1\
**Showing post:** 111

<div class="post-metadata">

**Author:** ![pganssle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pganssle/32/245_2.png) [@pganssle](https://discuss.python.org/u/pganssle)\
**Post date:** [February 4, 2019, 11:31am UTC](https://discuss.python.org/t/pep-517-backend-bootstrapping/789/111 "2019-02-04T11:31:35Z")

</div>

> [@takluyver](#):
>
> If we do decide to say build dependencies can be satisfied using pre-built wheels even when `--no-binary :all:` is set, I propose that we say the `--no-binary` flag doesn’t apply to fetching any build dependencies.

Unfortunately I think this does run up against at least one `--no-binary` use case we _do_ know about, which is that [some packages cannot be built as wheels](https://discuss.python.org/t/pep-517-and-projects-that-cant-install-via-wheels/791). My understanding is that `--no-binary` is doing double duty - it’s saying “don’t use a wheel if it exists” but it’s _also_ saying “don’t build a wheel as part of the install procedure”.

If you have build dependencies that cannot be built as wheels, having the `--no-binary` flag not apply to build dependencies would break your build. If the proposal is that the `:all:` selector simply doesn’t match build dependencies, but any explicitly-listed selections do, then I’m much more sympathetic. You _could_ add another selector like `--no-binary :all-build:`, but I think it would be a damp squib, since it would be broken for all packages that ultimately depend on `setuptools`, which at the moment is all packages.

> [@takluyver](#):
>
> It may not always be straightforward for the frontend to know the name of the project it’s trying to build (e.g. when you `pip install .` )

Presumably this is solved by the fact that you immediately recurse into a state where you _do_ know the name of the project you are building, because you’re trying to satisfy a build dependency. If I do `pip install .` for `setuptools` and it tries to install `setuptools` from source, it may not recognize that the name is the same, but on the next recursion it _will_ notice the name is the same.

That said, thinking about it more, we may not be able to get away with the “only have to break cycles of length 1” problem, at least not at the moment. I notice that if I add `setuptools` to `setuptools`’s `build-system.requires`, it fails building `wheel`, not due to some infinite regress or in building `setuptools`, because both `setuptools` and `wheel` depend on `['setuptools', 'wheel']` (`wheel` depends on these implicitly because it has no `pyproject.toml`). I think there are pretty simple solutions to this, but unless I’m way off the mark, it’s not as simple as I thought.

One more thing to note is that there’s a difference between _PEP 517_ saying you must resolve source build dependency cycles with wheels and _`pip`_ deciding to resolve source build dependency cycles with wheels. If we specify it in PEP 517, all compliant frontends _must_ do it that way. If we leave PEP 517 silent on the matter, frontends can do whatever they want (including not supporting non-wheel installs of build dependencies), though to be fair everyone’s going to optimize for however `pip` does it, so it will just become a _de facto_ part of the standard at that point.

---

_[View the full topic](https://discuss.python.org/t/pep-517-backend-bootstrapping/789)._