Skip to content
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

Does not delete all __pycache__ directories #108

Open
jwodder opened this issue Dec 7, 2023 · 2 comments
Open

Does not delete all __pycache__ directories #108

jwodder opened this issue Dec 7, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@jwodder
Copy link
Contributor

jwodder commented Dec 7, 2023

It seems that, currently, kondo only deletes __pycache__ directories located in the root of a Python project, but this is not the only place they can occur (and often there isn't even one in the root). A __pycache__ directory can be created in any directory containing a .py file, and .py files can be organized in any arbitrary assortment of directories with any depth.

@tbillington tbillington added the bug Something isn't working label Dec 7, 2023
@tbillington
Copy link
Owner

Do you have any good resources I could read about python project structures?

For example is it possible to "nest" python projects, or are all directories underneath considered part of the same "project"?

@jwodder
Copy link
Contributor Author

jwodder commented Dec 7, 2023

Do you have any good resources I could read about python project structures?

Not really. In a perfect world, this would all be documented at https://packaging.python.org, but that site is still lacking in many respects after many years.

Note that __pycache__ technically isn't specific to Python "projects" (if you're defining a project as anything more than a quick script) but rather something created by the python interpreter itself when an import statement is processed1; this link seems like a good overview.

For example is it possible to "nest" python projects, or are all directories underneath considered part of the same "project"?

I believe best practice is against trying to nest projects, but there are various ways to abuse some of the tooling to achieve nested projects. However, I don't think I've ever actually seen nested Python projects, and you should be fine with not trying to support such a (mis)feature.

Footnotes

  1. Unlike in Rust, in Python it's perfectly normal to write code without involving the packaging systems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants