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

[brettcannon]

@pf_moore

I certainly don’t want to be asked to specify a name and version every time I start a new project, and I’d be very unhappy if VS Code put some sort of “dummy” value in there - that would be just as bad as setuptools’ current behaviour of using UNKNOWN-0.0.0.

We would probably populate the name with the name of the directory and use a fake version number of 0 or something.

@pf_moore

But can we agree that any solution that mandates a specific named file would lose one important benefit of the requirements format, which is that the filename is up to the user?

Yes, although I will ask that if we do come up with a separate file which has flexibility in the name that the flexibility be limited for easier discoverability (*requirements*.txt is entirely convention and where people put an e.g. docs marker varies, if at all as they might use a subdirectory to namespace instead).

@pf_moore

If we allow project dependencies to be specified in pyproject.toml, we open up the possibility of tools expecting to write dependencies as a result of some sort of “add dependency” command

Yep, like Poetry, pipenv, and PDM already do (it’s covered by the table @courtneywebster has in the blog post).

@steve.dower

Or possibly [dev] with a dependencies key for dev dependencies?

This was brought up in Adding a non-metadata installer-only `dev-dependencies` table to pyproject.toml .

---

What I’m hearing in this discussion is two orthogonal questions:

1. Use pyproject.toml or a new file?
2. Should there be a way to able to provide data that even project.dependencies can’t represent, and if so what is that data?

The general trend seems to be that using pyproject.toml as-is isn’t a way most people want to go (maybe lukewarm, but no one seems to be screaming it’s the best solution and we should lean into it compared to trying to come up with a “proper” solution). It also seems like this would feed into whatever lock file format we eventually end up with by being what requirements.in is today for pip-tools (although I’ve been using it’s new pyproject.toml support in a project and liking it ).

So, do we want to try and come up with a top-level dependency-specifying solution for apps? If so, maybe the first step is trying to answer question 2 with what information we would want it to capture for app dependencies?