Work around top-level venv special case #468
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jherland
force-pushed
the
jherland/top-level-venv
branch
from
8bb16b1 to
339aaf7
Compare
jherland
force-pushed
the
jherland/top-level-venv
branch
from
339aaf7 to
e0bb9f2
Compare
This sample project has a virtualenv in the same directory as the project itself. Currently this causes FawltyDeps to find zero code and zero dependencies in the project.
Issue #465 highlights a peculiar case where the top-level project directory is also itself the root of a virtualenv. Our traversal code will skip any (given or detected) Python environment, under the assumption that we never want to analyze code/deps from a package installed within. However, we here have a special case where -- from the traversal code's POV -- we have found a pyenv rooted at a directory that also appears in the given settings.code and/or settings.deps (by default settings.code, settings.deps and settings.pyenvs are all "."). Work around this special case as follows: When a Python environment is found rooted at a path that is _also_ directly given in either settings.code or settings.deps, then we _don't_ want to skip traversal of the entire directory, rather we only skip traversal of the specific subdirectories that form the actual contents of the environment: - Any package dirs found by validate_pyenv_source() (i.e. any "site-packages" dirs). - The "bin/" (or "Scripts\" on Windows) subdir where we expect to find any tools installed into the environment. We could probably extend this handling to _any_ Python environment (including those found after we start the traversal proper), but I'm not 100% sure that this won't trigger false positives where some weird Python environment (e.g. a Conda or poetry2nix environment) happens to contain extra "stuff" missing from the above list that would adversely affect our analysis.
jherland
force-pushed
the
jherland/top-level-venv
branch
from
e0bb9f2 to
01b07c2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should solve issues #465.
Add special handling for the case were we have found a Python environment rooted at the same directory where we have been asked to look for code and/or deps.
Commits:
tests/sample_projects: Addtop_level_venvfor issue top-level venv doesn't work #465traverse_project: Better handle overlap between pyenv and code/deps dir