You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
setuptools build output (build/lib) analyzed as project code #159
Is your feature request related to a problem? Please describe.
File discovery (codeanalyzer/core.py ~line 870) walks project_dir.rglob("*.py") and skips only site-packages, .venv, and .codeanalyzer path parts. A project built with setuptools carries build/lib/** — byte copies of its package sources — so every module is analyzed twice (once under its real path, once under build/lib/...), inflating the symbol table and downstream graphs. Same bug class just fixed in codeanalyzer-java, where Gradle's build/resources copies of test fixtures leaked into analysis (codellm-devkit/codeanalyzer-java#199); found during that fix's propagation sweep. dist/ (sdist/wheel staging) and *.egg-info are worth the same look.
Describe the solution you'd like
build/lib (and dist, *.egg-info if confirmed) excluded from discovery
Failing test first: fixture with a build/lib copy of a real module yields one module, not two
Describe alternatives you've considered
Not stated in the original issue.
Additional context
Plan (optional)
None — small scoping fix.
Scope boundary
Discovery filter only. No schema change, no change to what a module contains — only which files become modules.
Caveats and known risks
A project with hand-written sources under a top-level build/ package would lose them — accepted, collides with setuptools' own output convention.
Definition of done
Test fails before / passes after; module count over the fixture equals the hand-counted set
Activity
[-]fix(discovery): setuptools build output (build/lib) analyzed as project code[/-][+]`setuptools` build output (`build/lib`) analyzed as project code[/+]