search

seddonym / import-linter

Import Linter allows you to define and enforce rules for the internal and external imports within your Python project.
https://import-linter.readthedocs.io/
BSD 2-Clause "Simplified" License
674 stars 46 forks source link

add [files ...] argument (similar to black, isort, mypy etc) #238

Open fraser-langton opened 1 week ago

fraser-langton commented 1 week ago

Specify subset of files to run import-linter on

eg lint-imports path/to/file_a.py path/to/file_b.py ...

Our pipelines all make use of git diff output to run checks ie CHANGED_FILES=$(git diff --name-only $BITBUCKET_BRANCH..origin/$BITBUCKET_PR_DESTINATION_BRANCH | grep '.py$')

black, isort, mypy all accept that output as arguments eg

isort --profile black --check-only $CHANGED_FILES
black --check $CHANGED_FILES
mypy $CHANGED_FILES

If this were to be added to import-linter, I think the goal would be to still calculate the entire import graph (grimp won't work well with partial modules) but only report on / fail on imports originating from [files ...]

There needs to some translation between filepaths and import expressions then maybe some functions in helpers.py can filter out "ignored" like you can from the config?

seddonym commented 1 week ago

Thanks for the issue!

I don't this this would work. Import Linter contracts aren't really about individual files (usually), they are more about the relationships between files.

Example: a contract specifies that blue should not import green, even indirectly. A change made to a different file could introduce a chain of imports between blue and green. So we'd need to check all files anyway. Does that make sense?

Out of interest, what problem are you trying to solve here? Is it speeding up the linter? If so I am actively working on rewriting much of it in Rust, which I hope will make a big impact.

fraser-langton commented 1 week ago

Thanks for the prompt reply!

It would be for reviewing only files files changed in the PR, ie so the rules can be introduced so and no code violates the contracts in new PRs.

Similar to how you might introduce mypy but not for the entire repo to allow time to migrate/update code.

It's not a speed thing because as you say all the files need to be graphed to find chained dependencies

seddonym commented 4 days ago

It would be for reviewing only files files changed in the PR, ie so the rules can be introduced so and no code violates the contracts in new PRs.

The way we achieve this at my workplace is by adding a list of ignored_imports and then treating that as a burn down list which we're not allowed to grow. Could that work for you?

fraser-langton commented 3 days ago

I can have stab at it if you want

seddonym commented 2 days ago

I don't think it needs a contribution to Import Linter, you should just be able to use the project as-is. Let me know if you're unsure how!