Say I have two projects in a monorepo:

root
|--projA/
|--projB/
|--pants.toml

Both use poetry and projB depends on projA. What would be the correct way to make this work with pants and poetry? Would projA be a path dependency (in poetry terms via pyproject.toml) that tailor picks up for pants? Or is another approach recommended?

What do

projA

and

projB

contain? Python code, or other kinds of dependencies as well? If it’s just Python code then you should be able to use dependency inference or explicit dependencies to import the right code from

projA

in

projB

In this case, both are python projects. I guess my question is in this scenario, would projB's pyproject.toml have something like:

[tool.poetry.dependencies]
python = "~3.11"
projA = "*"

and tailor taking care of setting up the Build files for the dependencies be enough, or is there a different, recommended approach.

If possible, I’d recommend combining the

pyproject.toml

files into one and then building your resolve in Pants using that combined file. Given that there is a dependency between the projects, you will need them to use the same resolve in Pants. The example you gave relies on

projA

as a package - you could build that package using

python_distribution

in Pants but you might also just be able to rely on the relevant sources directly

I guess this is representative of a more complex setup. In the real scenario, projA is using setuptools, while projB is using poetry and each are worked on by a separate subteam. I guess

python_distribution

could work, but then would it need a package every time projA is changed, or would the changes get picked up automatically? (And in the real scenario, there's also projectC which also happens to depend on projA).

Yeah, you would need to re-package every time the code changes and update the dependency in any downstream projects. This is one reason why using a common resolve + depending on the code directly might be easier - you’d also be able to detect breaking changes much faster if you have tests because any code changes in projA will be incorporated immediately into projB and projC.

so currently (without pants), we install projA as an editable dependency. When working on projB, if we change projA, it immediately gets reflected. Tests for A are run when publishing A, and / or B. Would something like this be doable in pants, or would we looking at restructuring things to make it work?

Definitely doable - the way we do this now at work is structuring the repo like this:

root
|--pyproject.toml
|--src/py
|----projA/
|----projB/
|----projC/

If all the source files are in the same repo, you might not need the editable dependency - you can just rely on the source files directly and trigger updated test runs based on the files that changed

ah... think I understand. Underneath projA, B, C they're all independent? Or do they all need to use poetry / the same thing?

I guess I don’t really understand this part of the question. Unless you need to publish A, B, C as packages then it doesn’t really matter? We use Poetry at the top level to define all of the dependencies but other than that there’s very little “project” configuration for the individual subprojects

in our case, it's completely different people working on projA and projB most of the time. TeamA doesn't like poetry, TeamB does. We could convert projA to poetry, but that'll take a little bit of effort, and a lot of grumbling. So we were wondering if these two so-far-isolated projects could be brought under a monorepo with the least amounts of friction.

Right, I guess I’m wondering - what does projA use setuptools for?

(in reality there are a few of these like projA). projA was created with pyscaffold... so the good old setup.py, setup.cfg, tox.ini, etc etc. In reality, this could all be poetry, but there's legacy stuff involved and the preference is to keep things inside the projects as minimally changed as possible.

Hmm yeah, I guess the main thing to extract in common would be the dependencies from the different projects. I’ve never used pyscaffold though so can’t speak to that part of it

cool... will try a few things. thanks for the insight.