Projects that aren't meant to generate a wheel and `pyproject.toml`

[brettcannon]

@pf_moore

if a project (in the broadest possible sense of the term) is not intended to be built into a wheel, is pyproject.toml an appropriate place to store project-level configuration?

I think so. With the level of adoption of [tool] I think this has already happened.

@pf_moore

Assuming it is, how do we reconcile the issue that as currently designed, the existing standardised data in pyproject.toml is very strongly tied to assumptions that are rooted in the “build a wheel” use case?

By adding other standardized data that isn’t “strongly tied to assumptions” around wheels? Seriously, we just use the file for other stuff. It’s to the point now that tools like Black only support pyproject.toml for configuration, regardless of whether you build a wheel or not.

@pf_moore

Personally, I’m not actually a fan of the “one huge config file” approach, and I prefer (for example) separate, focused requirements files.

I will say that when pyproject.toml gained popularity among tool providers, I was personally thanked multiple times for helping to tame the number of configuration files necessary for a project.

@pradyunsg

I will note that merely having a pyproject.toml file is sufficient for a project to be something that can be built into a wheel, since setuptools can and will happily proceed without any build configuration.

We have talked about revisiting that bridging default and dropping the implicit support.