I have a monorepo with several services, several libraries, many dependencies, etc and I’m having trouble trying to integrate Pants into it. I’ve simplified down to where a repo with just two folders each with a Pipfile fails to run Pants due to

ModuleNotFoundError

on any 3rd party dependencies that are shared, even if they’re the same version. How am I supposed to handle this situation?

Sorry to hear you’re having trouble. The easiest way to debug would be if you could post a trivial repo to github that demonstrates the issue!

@happy-kitchen-89482 thanks for being so quick to respond! (here and on the issue I posted, hehe) I’m happy to post a trivial repo to github, but first let me answer your responses I do in fact have two representations of the same 3rd party dep, and I have seen warning logs to that effect - it’s unclear to me why that’s an issue or more importantly how to resolve it though 😞

But generally we encourage having a single unified set of allowed requirements (aka “resolve”) for the entire repo, unless you truly need conflicting versions in different parts of the codebase

I would love for this to be the case, unfortunately the repo I am trying to integrate Pants into is a mess right now, with module different sets of dependencies, including a significant amount of overlap with different versions of the same 3rd party deps. Is there a way to tell Pants to treat it like different projects in the same repo? I had assumed that’s what

[source]

was for but that doesn’t seem to be the case

Without Pants you have to repeat requirements for every subproject/distribution/deployable thing, because that’s how the python package/deploy tooling works. But with Pants you just need a single “universe” of allowed requirements, and Pants selects the subset that you actually use in any given case. So it’s a different idiom.

Is it possible for this “universe” of allowed requirements to include multiple versions of dependencies? If not I may not be able to incorporate Pants into this repo, at least not until some significant cleanup has been done.. I’m hoping Pants can be a help in performing that cleanup though

That’s exactly what the “multiple resolves/lockfiles” feature is for

Interesting….I had started to try figuring out the multiple resolves thing earlier this afternoon but wasn’t sure whether it was relevant and gave up a little too quickly. I’m putting up a sample repo rn and as soon as that’s up I’ll give the multiple universes thing another shot

I’m going offline soon, but here is some reading material: https://www.pantsbuild.org/docs/python-third-party-dependencies#lockfiles

Sounds like you don’t need to see the example, but in case you’re interested: https://github.com/nikwotton/Broken-Pants-Demo

When I try to resolve both packages to the same universe though, it goes back to failing on the same errors as before

Can you explain what you’re doing here to cause the errors?

I mean I am trying to do as you describe here

Note however that the resolves represent “universes”, not projects. So if you have 20 different projects in your repo, but each can be assigned to one of 3 universes, you have 3 resolves, not 20.

I’m trying to use each package as a project with one shared universe/resolve. In case showing is better than telling, here’s the code: https://github.com/nikwotton/Broken-Pants-Demo/commit/d0ef5cdde4f10306c7da2a472f59d77b33a68c2b When I run

./pants test ::

it throws errors

That is exactly what I was just about to write

ahhhh

The two pipfiles create ambiguity

hmm, should both BUILD files still have this block then if only one of them has a pipfile?

pipenv_requirements(
    name="pipenv",
    resolve="packageA"
)