https://pantsbuild.org/ logo
Join Slack
Powered by
Hey there, small question: `pants fmt` moves my i...
# general
p
Hey there, small question: 
pants fmt
moves my imports like this:
Copy code
from dotenv import load_dotenv
from kittl.projects.my_project.ner import LogoNer, NerResult
but 
pants lint
complains about it and wants it like this:
Copy code
from dotenv import load_dotenv

from kittl.projects.my_project.ner import LogoNer, NerResult
Any idea of which settings in 
.isort.cfg
do I have to change? It currently is:
Copy code
[settings]
# This is to make isort compatible with Black. See
# <https://black.readthedocs.io/en/stable/the_black_code_style.html#how-black-wraps-lines>.
line_length=88
multi_line_output=3
include_trailing_comma=True
force_grid_wrap=0
use_parentheses=True

known_first_party=helloworld
default_section=THIRDPARTY
This is taken from https://github.com/pantsbuild/example-python
g
as long as your 
isort
is new enough, you should be able to use a 
pyproject.toml
with the 
profile = "black"
config as seen here. right?
s
you are probably running into https://github.com/pantsbuild/pants/issues/15069. the work-around is to manually specify all of your top-level first party packages in your isort config
g
does switching to 
ruff
solve the problem?
b
The good news is I have a fix locally for that issue 🙂
❗ 2
(actually maybe 2 fixes 😛)
p
That's great! Could you share them? 🙂
Specify all top level first party package in isort doesn't sound like a proper scalable solution
b
Ahh, fixes -> PRs upstream 🙂
In your case, though the workwaround is still to enumerate the top level packages (like 
kittl
)
s
Specify all top level first party package in isort doesn’t sound like a proper scalable solution
it is annoying, but unless you’re making new top-level dirs all the time I have found it’s not so bad in practice
(agreed it is not “proper” though)
p
Sounds good! Would it be much trouble to show an example of how I should enumerate them in the config file? 🙂
s
so if you have something like:
Copy code
your_source_root/
  service1/
  service2/
  lib1/
  lib2/
then you’d put 
known_first_party=service1,service2,lib1,lib2
(
your_source_root
being the root of the 
PYTHONPATH
/ the source root configured in 
pants.toml
)
for your specific case 
known_first_party=kittl
might be enough
p
Thank you so much! 🙂 I tried to put: 
known_first_party=kittl
as well as 
known_first_party=kittl,projects,my_project
and the issue remains, really strange
I'm wondering if there's something wrong I am doing?
My .isort.cfg now is:
Copy code
[settings]
# This is to make isort compatible with Black. See
# <https://black.readthedocs.io/en/stable/the_black_code_style.html#how-black-wraps-lines>.
known_first_party=kittl,projects,ner_logo_gen
multi_line_output = 3
include_trailing_comma = True
force_grid_wrap = 0
use_parentheses = True
ensure_newline_before_comments = True
line_length = 88

default_section=THIRDPARTY
c
also good to be aware of this issue with 
isort
in combination with pants sandboxing: https://github.com/pantsbuild/pants/issues/15069
g
woah, i didn't know the order of backends behaves like that. not certain that's causing a problem here but... you could reorder black and isort? ha.
c
even if you run them in different order, they would still disagree on the format without proper configuration.
✅ 1
Open in Slack
PreviousNext
Powered by