Hi all, I'm having trouble getting isort to work correctly with multiple "projects" within a monorepo: isort classifies my python modules as third-party. I posted a question on SO: https://stackoverflow.com/questions/75869900/pants-with-isort-thinks-my-python-modules-are-third-party. Thanks in advance!

are u sure isort picks up your isort config file ? We use it this way:

setting the config file location didn't work. I don't think this is an isort config problem, because I can use isort successfully without pants. I think it has something to do with how pants invokes isort.

you can use this tip: https://www.pantsbuild.org/docs/troubleshooting#debug-tip-inspect-the-sandbox-with---keep-sandboxes to inspect how pants invokes isort.

do you have your repo setup with multiple top level projects?

no. all of our python sources are under

src/python/

so there might be an actual limitation or an issue with pants here if you have multiple top level projects. I am not that familiar with pants and how it works in those cases...

This might be https://github.com/pantsbuild/pants/issues/15069: the exact split pants decides to do for running isorts in parallel on different files can change what isort deduces as first party or not.

The thing is, it always works when my modules are organized under

src

. but it never works when they're under

project/src

That’s interesting, although it may still be up to the wiles of pants automatic decision making about file grouping/sandbox contents. I believe it’s deterministic for a fixed repo configuration, but may change as the config/layout changes, so the

project/src

layout may happen to split things in a different way to

src

forked from the python example repo. It would be great if we can update the official example repo once we figure this out. Because these are day 1 frustrations that caused me to abandon pants last time.

Yeah, we’ve had frustration with pants and isort in our work repo too. I acknowledge the discouragement!

I wonder if it has to do with isort's own idiosyncracies: https://github.com/PyCQA/isort/issues/1497

Yeah, we still use it, and have a multi-project monorepo. We use the workaround in https://github.com/pantsbuild/pants/issues/15069#issuecomment-1174460553 . Here's the relevant snippet from the

pyproject.toml

[tool.isort]
...
# FIXME: <https://github.com/pantsbuild/pants/issues/15069>
# isort and/or pants doesn't seem to reliably identify first party properly (e.g. it'll tell that
# foo is, but not foo.bar, even in a single file!), so just check everything into one
# section... plus this is closer to zimports
default_section = "FIRSTPARTY"

That's funny about the FIRSTPARTY fix, because the pants docs say to set that to THIRDPARTY: https://www.pantsbuild.org/v2.1/docs/python-fmt-goal

Weird! We don't set any

known_first_party

like that example, which might be the difference...

The FIRSTPARTY workaround collapses first and third party into one section, which I'd rather not do

Yeah, it's not the best, but we've found the other benefits of pants to be worth it and it's better than not having import sorting at all. 🤷‍♂️ / 😦

you're onto something with the known_first_party thing though.

Putting

.isort.cfg

into

project1

(i.e.

mv .isort.cfg project1/.isort.cfg

) seems to give the right behaviour, so I wonder if this is an interaction between config file location and first party inference within isort

the isort ticket I linked above does indicate that config location impacts behavior of first/third party.

ah, I hadn't read it in enough detail, there we go 👍

but the thing that's still confusing is that if you just move the

src

directory up one level everything works correct

That suggests to me that the relative position of

.isort.cfg

and

src

is what matters: if they're adjacent, it gives good behaviour; if they're not (including if it's not exactly called

src

), it gives 'bad' behaviour?

but I have an existing repo where the source lives under folders named python. so... I need an actual solution to this problem.

When I run

isort

outside of pants, it looks like a broken config file is just a warning and the process succeeds overall:

/Users/huon/.pyenv/versions/3.9.10/lib/python3.9/site-packages/isort/settings.py:771: UserWarning: Failed to pull configuration information from /private/tmp/pants-example-python/.isort.cfg

So, pants won't pass this through by default (since it'll only surface true failures).

good tip.

BTW, once we resolve all of this isort behaviour, that's not caused by pants, unfortunately, I think the only reliable way to get consistent isort behaviour in a large pants repo (where isort might be running in parallel on subsets of the files) is to not rely on inference. In particular, its inference seems to depend on the exact files visible to isort when it runs, and this may not be the full set with pants sandboxing (and may change as files are added/moved/deleted), i.e. https://github.com/pantsbuild/pants/issues/15069 . Two ways to not rely on inference: • the workaround we use: not splitting first and third party 😞 • manually specifying all

known_first_party

modules 😞

I can confirm it's finding the config file

Ah, yeah, sounds like you're hitting the limits of isorts inference anyway, so manually specifying

known_first_party

might be what you need to do. Just thinking out loud, one option to not need to specify info in multiple places would be to generate the file using info that pants knowns, e.g. add all the subdirectories of each folder in

pants roots

(or something more intelligent). You might want a CI check that the file is up to date, in addition 🤔

Re renaming src changing behavior, I'm guessing this is related to the default source roots. What do you see in each case when you run

pants roots

?

changing the pants roots has no effect

I'd still drill into this - you're seeing behavior that relies on a directory specifically named

src

, and the only thing in Pants that knows about that naming convention is the default source roots.

yep, the roots are correct

I'd still drill into this - you're seeing behavior that relies on a directory specifically named

src

, and the only thing in Pants that knows about that naming convention is the default source roots.

(FWIW, running

isort

outside of pants depends on the

src

name literally too, so there's not (only) a pants interaction here.)

@happy-kitchen-89482 if you take a look at my simple repro repo you'll see the source roots are set correctly: https://github.com/chadrik/pants-example-python

Hm, I'm a bit confused. I get the same behaviour in that example repo with external isort vs. pants-run isort?

pants export --resolve=isort # (get a venv with the right version of isort)
dist/export/python/virtualenvs/isort/*/bin/isort .

makes the same change to

helloworld/main.py

as

pants fmt ::

In a real-world multi-project monorepo you would set isort

src_paths

in the config file to e.g.

project1/src

. It was my assumption that pants was providing the pants source_roots as the isort src_paths, but it seems that it is not. I'm pretty sure that's the right behavior, though.

Ah, the repro repo is gold, that is always the best way to get help, so thanks for posting that. I will take a look at it.

I'm going to push up a change to remove helloworld from the known_first_party

AFAIK, Pants doesn't set

src_paths

automatically (similar to how it doesn't set

known_first_party

directly), so I think that'll be why we observed the position of the

.isort.cfg

file and

src

directory name mattering

So, in the example repo the issue is that

allthing

isn't in the known_first_party

I don't know anything about pants sandboxing. is it possible to disable, or to ensure that all relevant files are included in the sandbox, for users for whom correctness is more valuable than performance?

Pants runs everything in sandboxes, it's what makes caching and concurrency possible. But in this case the issue is also just scale in general - unless you want to run isort on all you code every time, you might be in a situation where it doesn't know about some of your first-party code. So

known_first_party

is probably the best path forward here. Unless you have a large number of first-party top-level packages? Usually people have just one, or at most a handful.

So

known_first_party

is probably the best path forward here. Unless you have a large number of first-party top-level packages?

yep, we have a lot of known_first_party modules. there's a possible solution using pre-commit hooks to write the known_first_party field in the config file. Is there a way to get that list from pants?

Hmm, let me think of a better solution then

as I said, I'm totally ignorant of pants's sandboxing, but having a set of limited global info that's shared across sandboxes seems valuable for things like this.