https://pantsbuild.org/ logo
#general
Title
# general
p

proud-dentist-22844

08/10/2021, 7:25 PM
Eventually, I want to adopt poetry in the monorepo I'm working on adding pants to. So, I've been watching the development of both pants and poetry. Pants can extract poetry-style dependencies from multiple pyproject.toml files already. Plus, I just saw an interesting plugin for poetry: https://github.com/jacksmith15/poetry-workspace-plugin How might this plugin make a difference for pants? Looking it over, it doesn't really offer coordination of dependencies or constraints besides adding path-based dependencies on projects in the repo. Where would might this plugin be useful in a pants+poetry repo?
b

busy-vase-39202

08/10/2021, 7:50 PM
I'd love to get @steep-breakfast-98857's thoughts on 👆 and https://pantsbuild.slack.com/archives/C046T6T9U/p1628623771201600
w

witty-crayon-22786

08/10/2021, 10:25 PM
Pants can extract poetry-style dependencies from multiple pyproject.toml files already.
one thing to know about this (which the blog post alludes to: https://blog.pantsbuild.org/poetry-support-for-pants-2-6/): it’s challenging to gain the full advantage of Pants with a bunch of different `pyproject.toml`s. dependency inference is likely to be ambiguous if they have overlapping dependencies. certainly our ambition is to be better than poetry when you need to manage lots of projects in one repo, and so in some cases “lots of `pyproject.toml`s” will be one step along a migration.
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.
w

witty-crayon-22786

08/10/2021, 10:51 PM
Hm, yea... maybe. All of that is possible right now aside from the
poetry_distribution
... I'm not sure how much that saves over putting the metadata directly in the BUILD file. Unless poetry can still do something useful with it when it's in
pyproject.toml
...?
p

proud-dentist-22844

08/10/2021, 10:58 PM
dunno. Maybe once I get that far I'll compare pants vs poetry built distributions
Man, I really could use more time 😛
💯 1
b

busy-vase-39202

08/11/2021, 5:03 PM
If you do, it'd make a fascinating blog post.
👍 1