# Status of "\`pyproject.toml\` presence triggers different pip behavior" **URL:** \ **Category:** Packaging\ **Created:** [September 16, 2022, 8:05am UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156 "2022-09-16T08:05:23Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![astrojuanlu](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/astrojuanlu/32/703_2.png) [@astrojuanlu](https://discuss.python.org/u/astrojuanlu)\ **Post date:** [September 16, 2022, 8:05am UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/1 "2022-09-16T08:05:23Z")
I was about to recommend someone add a `pyproject.toml` file to their project to declare build-time dependencies following PEP 518, but then I remembered these old threads about the presence of the file triggering potentially problematic behavior for old projects: - [pyproject.toml (PEP 518) support · Issue #234 · PyCQA/flake8 · GitHub](https://github.com/PyCQA/flake8/issues/234) - [Offer option other than pyproject.toml for config · Issue #683 · psf/black · GitHub](https://github.com/psf/black/issues/683) These threads are old though, and I understand that lots of things have changed ever since. What is the current status of the issue? Should users still be wary of the _presence_ of `pyproject.toml` files on their projects? Or with the standardization of editable installs etc are all the shortcomings basically solved? ---
**Author:** ![hauntsaninja](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hauntsaninja/32/12451_2.png) [@hauntsaninja](https://discuss.python.org/u/hauntsaninja)\ **Post date:** [September 16, 2022, 9:11am UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/2 "2022-09-16T09:11:16Z")
pip still uses the presence of pyproject.toml as a signal that it can use isolated builds for editable installs. In my experience, this doesn’t cause too many problems, so I think after various bugs were fixed most people just moved on from complaining about it. To me it seems checking for the [build-system] table in pyproject.toml would probably have been better, but that ship has probably sailed. So don’t get your hopes up for flake8 supporting pyproject.toml! In particular, for pure Python packages the only problem I’ve had is that isolated builds cause editable installs via pip to be 2-3x slower. For extension modules, isolated builds matter more since you tend to actually have build requirements. For the most part when it’s come up for me, it’s the kind of breakage that’s good and leaves you with more reproducible builds going forward. It can be annoying if you need a specific build of some package installed in your build environment though. ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [September 16, 2022, 12:21pm UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/3 "2022-09-16T12:21:59Z")
There’s no major missing bits of functionality with pyproject.toml-based builds but there’s still a difference in behaviours. As noted in [Build System Interface - pip documentation v22.2.2](https://pip.pypa.io/en/stable/reference/build-system/), we’re working toward removing non-isolated builds via direct `setup.py` invocations within pip _entirely_, at some point in the future. For that to happen though, there’s a few missing pieces: using proper virtual environments for the isolation, killing `setup.py install` and speeding up the build times via caching/reusing build environments (eg: setuptools + wheel is a common base environment setup). This is the tracking issue: > > > Currently if you try to \`\`pip install\`\` something that only is provided a "legac…y" setuptools only sdist without a \`\`pyproject.toml\`\`, that will be installed using the "legacy" path unless you explicitly invoke \`\`--use-pep517\`\`. > > This is particularly troublesome in cases where you don't have (or want to have) setuptools installed in the environment, since the legacy path depends on having setuptools preinstalled. > > This flag does not affect editable installs in any way, and those still require having setuptools preinstalled in either case. > > This seems like it would be a good stepping stone on the way to https://github.com/pypa/pip/issues/6334, since it narrows the cases where we're using the legacy path to just editable installs. ---
**Author:** ![bryevdv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bryevdv/32/7424_2.png) [@bryevdv](https://discuss.python.org/u/bryevdv)\ **Post date:** [September 16, 2022, 4:21pm UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/4 "2022-09-16T16:21:42Z")
> [@hauntsaninja](#): > > So don’t get your hopes up for flake8 supporting pyproject.toml! OT: I truly don’t understand their intransigence on this point. The folks who want to use `flake8` with `pyproject.toml` _have already accepted the differences implied by having a `pyproject.toml`_. But I digress. There is some hope they will add a configuration hook that plugins can use, at least. 🤞 ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [September 16, 2022, 6:38pm UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/5 "2022-09-16T18:38:30Z")
> [@hauntsaninja](#): > > So don’t get your hopes up for flake8 supporting pyproject.toml! This is unfortunate, as flake8 really is the last hold out for fully embracing `pyproject.toml`, at least for the tools I use in OSS and in my work environment. In the interest of minimizing config files, I’m at least glad you can configure flake8 in `tox.ini` and that’s what I use. I’ve been able to completely ditch `setup.py` and `setup.cfg` and am not looking back. I’m mixed on whether tox should also fully support `pyproject.toml`. I know they have the legacy config, but putting a string in `pyproject.toml` isn’t compelling enough. I’m also not totally sure I _want_ `pyproject.toml` to replace `tox.ini` in my code. I kind of like separating local development and project metadata/installation requirements, but OTOH maybe one ring to rule them all would be better in the long run. ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [September 16, 2022, 7:51pm UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/6 "2022-09-16T19:51:38Z")
This tweet (and those around it) have some relevant context on the flake8/pyproject.toml situation. > A part of the problem for flake8 is that the configuration system is closely coupled with the ini file format and exposed to plugins; causing a mix of compatibiility, implementation and migration concerns. ---
**Author:** ![bryevdv](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bryevdv/32/7424_2.png) [@bryevdv](https://discuss.python.org/u/bryevdv)\ **Post date:** [September 16, 2022, 8:21pm UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/7 "2022-09-16T20:21:02Z")
> [@barry](#): > > This is unfortunate, as flake8 really is the last hold out for fully embracing `pyproject.toml`, `pre-commit` (notably, by the same author as `flake8`) is also a holdout, though admittedly with a [better rationale in that case](https://github.com/pre-commit/pre-commit/issues/1165#issuecomment-862603032) (at least until toml widely supports more hierarchical data better). > A part of the problem for flake8 is that the configuration system is closely coupled with the ini file format and exposed to plugins; causing a mix of compatibiility, implementation and migration concerns. I actually [made an issue regarding a new plugin hook](https://github.com/PyCQA/flake8/issues/1657) that would allow overriding config collection, so that at least there could be a supported path self-service here. I even offered to submit a PR for it, but was asked not to. However, things did, in fact, look rather simple to me, with [one function that returns a `dict[str, Any]`](https://github.com/PyCQA/flake8/blob/6027577d325b0dd8bf1e465ebd29b71b5f0d005b/src/flake8/options/config.py#L96) that gets merged with cmdline args then used by subsequent codepaths. So TBH I don’t understand those comments, but 🤷‍♂️ guess I must have missed some details somewhere. Love the snark abut “8 config files instead of 9” though—currently we have three config files instead of one, and two of them are for his tools. 🤣 ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [September 16, 2022, 11:11pm UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/8 "2022-09-16T23:11:53Z")
> [@astrojuanlu](#): > > Should users still be wary of the _presence_ of `pyproject.toml` files on their projects? In general, I think no. Now is a great time to fully embrace `pyproject.toml` and get rid of the legacy setuptools stuff. It’s not completely seamless though. One thing that would help my projects is some additional standardization in the `config_settings` that are passed to the backends. For example, I reported a [problem to pdm-pep517](https://github.com/pdm-project/pdm-pep517/issues/123) where its default use of a `build/` directory clobbered a similarly named directory used by my work’s build system. If I could define the build directory in a standard way in `pyproject.toml` and ensure that that was passed in a consistent way to any build backend through the `config_settings` dictionary, it would help us out a lot. ---
**Author:** ![ofek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ofek/32/1033_2.png) [@ofek](https://discuss.python.org/u/ofek)\ **Post date:** [September 17, 2022, 4:30am UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/9 "2022-09-17T04:30:52Z")
The concept of a temporary build directory in the project directory is backend-specific; Hatchling does not do that and never will. As far as `config_settings` goes, I find it generally useless/unintuitive, so Hatchling uses [environment variables](https://hatch.pypa.io/latest/config/build/#environment-variables). ---
**Author:** ![layday](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/layday/32/2771_2.png) [@layday](https://discuss.python.org/u/layday)\ **Post date:** [September 17, 2022, 9:46am UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/10 "2022-09-17T09:46:08Z")
> [@bryevdv](#): > > `pre-commit` (notably, by the same author as `flake8`) is also a holdout, though admittedly with a [better rationale in that case](https://github.com/pre-commit/pre-commit/issues/1165#issuecomment-862603032) (at least until toml widely supports more hierarchical data better). pre-commit is not specific to Python projects; it’s a development tool which happens to be written in Python. If we’re gonna draw the line somewhere, I think that’s a pretty good place. ---
**Author:** ![astrojuanlu](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/astrojuanlu/32/703_2.png) [@astrojuanlu](https://discuss.python.org/u/astrojuanlu)\ **Post date:** [September 19, 2022, 6:24am UTC](https://discuss.python.org/t/status-of-pyproject-toml-presence-triggers-different-pip-behavior/19156/11 "2022-09-19T06:24:02Z")
Thanks all for your answers. To be clear, I was not asking this to debate the flake8 situation - I couldn’t care less about having one more config file. I’ll keep an eye on [Default to isolated, pyproject.toml-based builds · Issue #9175 · pypa/pip · GitHub](https://github.com/pypa/pip/issues/9175) (I was already subscribed apparently).