-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow banning of certain modules and certain module members #1422
Comments
Thanks for writing this up! I think the most straightforward path would be to model this after We can start by using the same API as |
It looks like I know that doesn't solve your |
Let me know if you're interested in implementing, and I could write up some more specific instructions. |
Good point, should we open a separate issue for that?
According to its README
but only when they're imported as e.g.
I am not sure how much sense it makes to have two separate checks for this because With this side-effect in mind I think it makes sense to properly check for attribute access as well, at which point the check is more than I251, ... I am not sure if using an existing identifier implies that the check by ruff is exactly the same? Yes I'm interested in implementing this :) |
It's filed here: #835. (I linked the wrong issue above, edited.)
Yeah! I saw that too. What I meant was that it doesn't detect module accesses as in the issue you linked. I was mostly suggesting that should be a separate check so-as to maintain compatibility with |
Great! There are some instructions on adding check codes in general in the contributing guide. For this code, you'd then want to do two things above those initial steps:
|
I'd kind of prefer to avoid implementing all of the wildcarding that I also can't really find any usages of the wildcarding in code search. So, IMO, let's skip that for now. |
(You can just ping here as you have questions, I'm happy to help.) |
I think naming it |
Thank you for your contribution, and for bearing with my feedback! It's hugely appreciated! I'm really glad to have you as a contributor :) |
I use a the wildcard syntax in a project, so the config ends up being: [flake8]
banned-modules =
httpx.* = Use kodiak.http
ban-relative-imports = true My use case is preventing people from importing Maybe there is a way to achieve this without the example uses (in the wrapper module) that flake8-tidy-import lints: from httpx import ( # noqa: I251
AsyncClient,
HTTPError,
HTTPStatusError,
Request,
Response,
)
from httpx._config import DEFAULT_TIMEOUT_CONFIG # noqa: I251
from httpx._types import TimeoutTypes # noqa: I251 |
Would |
Oh yeah that's what I should have been using, didn't know about that! I'll make a separate issue because I think the following config isn't working: [tool.ruff.flake8-tidy-imports]
# Disallow all relative imports.
ban-relative-imports = "all"
[tool.ruff.flake8-tidy-imports.banned-api]
"httpx".msg = "Use kodiak.http" |
Go for it, I haven’t used that plug-in a ton yet myself but happy to take a look. |
Sometimes you want to assert that certain modules are never imported. Apparently Pylint and Pyflake have plugins for that (pylint-restricted-imports and flake8-tidy-imports respectively).
I think the disallowed modules / module members could be defined in a new
tool.ruff.banned-api
section inpyproject.toml
. So you could for example have:Note that banning module members is a bit challenging because we also have to account for attribute access e.g.
I think it is quite clear that it is impossible for such a lint to prevent all the ways an API can be accessed, for example banned modules could still be accessed via
importlib
oreval
and banningeval
is a hopeless endeavor because there are countless ways of accessing it e.g.globals()['__builtins__'].eval
or evendataclasses.builtins.eval
. Completely preventing attribute access is even more difficult because you'd have to understand data flows (e.g.(lambda x: x.evil_function())(example)
).So I just think the documentation of the lint should clarify that it's meant to prevent accidental usage of the API and can be easily circumvented.
Aside from such false negatives the attribute access check would probably also result in false positives e.g.
So I think the error message for detected attribute access should say something like "it looks like you used a banned API" instead of using assertive language that might confuse users.
Lastly in cases where the fix is just replacing one import for another (e.g. changing
typing.TypedDict
totyping_extensions.TypedDict
) it would be nice if ruff could provide automatic fixing via--fix
. This is also the reason why I suggested the.msg
in the previous config example because then we could additionally specify e.g:I have not contributed to ruff yet, but if the people here like the suggested lint, I could look into implementing it :)
The text was updated successfully, but these errors were encountered: