the poetry workspace command is definitely interesting, and provides some of what pants would… but it still has the boilerplate of redundant `pyproject.toml`s and a workspace definition that lists all of them.

… and depending on the implementation of the workspace command, it might potentially be trying to fork

poetry

a bunch of times rather than actually managing concurrency in process.

It uses subprocess

It seems to me, that a more hybrid approach would work better. • Keep all dependencies in the root

pyproject.toml

alongside the root

poetry.lock

file. • Sub-projects (or workspaces to use the term from this plugin) would still have a

pyproject.toml

but only for non-dependency metadata (see https://python-poetry.org/docs/pyproject/), including: ◦ simple metadata: name, description, license, authors, maintainers, readme, homepage, repository, documentation, urls. ◦ distribution metadata: ▪︎ keywords, classifiers, ▪︎ scripts, plugins (ie entry_points) ▪︎ packages, include/exclude, (maybe not these when used w/ pants) ◦ managing extras would get weird here

Then, pants would need to learn about

poetry_distribution

and presto! each of those subprojects could define its distribution.

Man, I really could use more time 😛