Hi all, I'm in the process of converting my team's monorepo to pants for a proof of concept, but i'm getting stuck trying to run the typecheck goal on all targets, i.e.

./pants typecheck ::

. The error is

ProcessExecutionFailure: Process 'Building requirements.pex with 24 requirements

because it is trying to install two conflicting versions of a third party package. One version is defined in the 3rdparty directory, the other is defined in an individual library's BUILD file. The typecheck goal works fine when addressing individual targets and other goals (like test) work fine when addressing all targets (

./pants test ::

). For a bit more of a concrete example,

project_a

uses

third_party_lib==0.5.0

while

project_b

,

project_c

, and

project_d

use

third_party_lib==1.0.0

.

project_a/BUILD

contains a

python_requirement_library

called

old_third_party_lib

and its

python_library

depends on that target. If I run

./pants typecheck ::

it seems to try to build a single

requirements.pex

containing all of the requirements for all of the targets which is where the

third_party_lib

conflict happens. For now I can probably just run typecheck on each target individually (or split based on dependees or whatever) but I'd like to be able to sell the ease of

./pants typecheck ::

to my teammates when I present this to them. Any ideas?

Oh huh, that's a really interesting dilemma. Indeed, this works with

test

because we run

test

as a separate process per-file, and each file can have its own resolve But for typecheck, we batch it, in large part for performance so that we're not invoking MyPy lots of time For

fmt

and

lint

, we have a

--per-file-caching

option that will change the strategy from one process for the whole batch to one process per file. I'm wondering if that might make sense for

typecheck

..it would address your issue iiuc. Only, I imagine the perf would be pretty atrocious (and Pants's MyPy perf is already pretty bad, with plans to improve)

Ah I see, thanks! For now I might be able to get away with annotating the project that uses the outdated dependency and filtering it out

That makes sense: https://www.pantsbuild.org/docs/advanced-target-selection#tags-annotating-targets Pardon that it's a little clunky having to remember to use the

--tag

we’re also going to be kicking off a project to resolve this issue more deeply soon: https://github.com/pantsbuild/pants/issues/11165