Hey I’m trying to integrate the

isort

backend using v2 with pants version

1.30.0

. Is there a way for

isort

to know about 3rdparty dependencies? In order to sort them into a separate section from buildins and first-party files. Normally I believe it looks at the environment to tell if something came from pip. I’m not sure how to do this in pants. I’ve declared the dependencies in a file

3rdparty/requirements.txt

and invoking

python_requirements()

Hi Charlie! Are you using isort 4 or isort 5? Their algorithm changes for how they classify imports

I’m using

pants.backend.python.lint.isort

I didn’t specify version.

Cool, that means that you’re using the default of isort 4, which works better. We do not pull in third party requirements when running isort. This makes it much faster because we don’t have to resolve requirements and we don’t have to invalidate the cache if you change your requirements. Instead, we recommend adding a top-level

.isort.cfg

file to your project with settings like this:

[settings]
known_first_party=myorg,myorg2
default_section=THIRDPARTY

Replace

myorg

with the names of your top-level package, like

pants

or

django

. Then, set this in `pants.toml`:

[isort]
config = [".isort.cfg"]

That makes sense of why it’s not an option. I was hoping to do the first party method since my project has a very flat structure to it and I didn’t want a huge list there. It seems like a good approach though.

since my project has a very flat structure to it

Got it. It may make sense to then invert it so that you set the default section to first party, and you enumerate each 3rd party req used. Although, I suspect it’s more common to add a new third party req than it is to add a new top-level package name, so it may be more robust to stick with defaulting to third party.

Pants now has the idea of

module_mapping

for third party in order to do dependency inference. I wonder if there could be a solution using that to build a list of known third parties and inject that into isort

Indeed, we do now have

module_mapping

! That’s an interesting idea. I think possibly we could use that to try to intelligently auto-configure the config file with the names of the modules? I think we’d be a little hesitant to modify a user’s config file like that, though. A general theme of the v2 engine and upcoming 2.0 release is making Pants less magical. We generally want you to be able to run the same tools without Pants, and it would still work.