I think I’ve run into a bug with

pants fmt

and isort, I’m seeing different behaviours invoking the tool manually vs invoking it via pants. I think it might be similar to what’s described in https://pantsbuild.slack.com/archives/C046T6T9U/p1686656639591789 Running

pants fmt --only=isort main.py

Changes my file

from flask import Flask, request
from lib.x.x import square
from marshmallow import Schema

In comparison to running

dist/export/python/virtualenvs/tools/isort/bin/isort main.py

Changes it to

from flask import Flask, request
from marshmallow import Schema

from lib.x.x import square

The latter of which looks more sensible I have a reproducible (hopefully) example repo here: https://github.com/Jackevansevo/pants-isort-weird

isort is the bane of my existence.

Interestingly if I

rm -rf lib

I get the same result for both tools. To answer your Q

pants lint ::

Gives me

✓ black succeeded.
✕ isort failed.

If the file was previously sorted with

isort main.py

But passes if I’ve first done

pants fmt --only=isort main.py

So pants fmt / lint seem to agree here. Both seem to want to always change

main.py

pants fmt --only=isort main.py
pants pants --only=isort ::

Yeah, so this is classic "the presence of lib affects what isort considers first party vs third party"

nice, it looks like adding

known_first_party = ['lib']

Indeed fixes the issue Many thanks for diving into this and helping out Benjy, much appreciated.

Sorry for the trouble. Unfortunately isort's expectation of knowing the entire universe is not very compatible with pants's sandboxing model.