Auto-deactivate venvs in $PROJECT_HOME without requiring .project files #209
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
This is an attempt to improve my previous pull request about making the auto-activation plugin project aware (justinmayer#175). The solution back then was to only deactivate virtualenvs of projects automatically if they contain a .project file. However, this solution feels very unintuitive to me, partly because it seems against the 'intended' use of the projects plugin, which suggests to only use .project files if the project is not in the $PROJECT_HOME directory - and I like to keep all my projects in $PROJECT_HOME. This patch aims to accommodate this workflow by auto-deactivating virtualenvs of projects in $PROJECT_HOME without needing .project or .venv files. It adds a check to the auto-activation plugin: auto-deactivate venv if a) it's not auto-activated and doesn't contain a .project file, AND b) it's not a subdirectory of $PROJECT_HOME. By testing for these very specific conditions, this patch should not interfere with the normal usage of .venv and .project files in any way.
|
Makes sense to me. Well done! 💫 |
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 is an attempt to improve my previous pull request about making the auto-activation plugin 'project aware', so that virtualenvs of projects are automatically deactivated when leaving the project directory (#175). The solution back then was to only deactivate virtualenvs of projects automatically if they contain a
.projectfile. However, this solution feels very unintuitive to me, partly because it seems against the 'intended' use of the projects plugin, which suggests to only use.projectfiles if the project is not in the$PROJECT_HOMEdirectory - and I like to keep all my projects in$PROJECT_HOME.This patch aims to accommodate this workflow by auto-deactivating virtualenvs of projects in
$PROJECT_HOMEwithout needing.projector.venvfiles. It adds a check to the auto-activation plugin that auto-deactivates venvs if all of these conditions are true:.projectfile$PWDis not a subdirectory of$PROJECT_HOME(because projects are stored as$PROJECT_HOME/project1-dir,$PROJECT_HOME/project2-diretc.)By testing for these very specific conditions, this patch should not interfere with the normal usage of
.venvand.projectfiles in any way. Implementing this required very few code additions and the interaction between the auto-activation and projects plugin feels more intuitive to me: Now I can continue to use the projects plugin 'as intended' while benefiting from the convenience of the auto-activation plugin.I've also updated the old comments explaning Projects plugin compatibility to reflect this change.