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
It would be nice if users who were using argcomplete in a virtualenv could get the benefits of activate-global-python-argcomplete without having their global shell configuration files modified. That is, without modifying ~/.zshrc, ~/.bash_completion, or any other file used in a context outside of the existing virtualenv (or at the very least, without having these global files reference/source files in the virtualenv)
Motivation
Virtualenv's are frequently non-permanent environments that live on users systems; it is common for them to be destroyed, recreated, etc. This is especially true for developers who might spin one up per-project and may reinstall it every time their python version increases.
Currently, activate-global-python-argcomplete modifies both ~/.zshrc, ~/.bash_completion, having them source files within these transitory environments. This leads to multiple problems, 3 such problems are:
These files may not exist if these transitory environments were removed, any security implications about sourcing files that do not exist but could be created aside, this could lead to unexpected consequences; for example, someone might deletes their test virtualenv then recreate it yet not run activate-global-python-argcomplete; but due to the previous activate-global-python-argcomplete run the autocompletions files might be sourced if the paths happen to be the same. This isn't likely a catastrophic danger or anything, but I'd argue it's someone counter to how virtualenvs are generally expected to behave
These completions may be undesired outside of the virtualenv. A user might not command completions to activate on a given command when not using said command in the virtualenv. This could be for multiple reasons, but one obvious one is just to reduce the amount of unnecessary shell code that runs on shell startup.
Duplicate code. If a user has multiple virtualenvs each with argcomplete installed via activate-global-python-argcomplete, each one of those would be loaded on shell login. I'm not sure if this has other side effects.
Solutions
I am not quite sure what a good solution for this would be, but I can think of a few things:
activate-global-python-argcomplete can either detect if it's in a virtualenv and respond accordingly, prompt the user, or an activate-virtualenv-python-argcomplete command can be provided
activate-virtualenv-python-argcomplete can append to: /home/me/.virtualenv/my_venv/bin/activate something like the following:
if [ -n"$ZSH_VERSION" ];then
fpath=( /path/to/completions "${fpath[@]}" )
reload-completions # However this is done in zshelif [ -n"$BASH_VERSION" ];thensource /path/to/completions
reload-completions # However this is done in bashfi
activate-virtualenv-python-argcomplete can prompt the user asking where this should be written
activate-global-python-argcomplete could install it's config files outside of the virtualenv (if they will work for all virtualenvs). At that point, it could either be that it activates for all argcompletes in all virtualenvs and the global space, or it have it check the current ENV to determine if it is in a virtualenv that activated locally- either is a solution though both obviously have tradeoffs.
The text was updated successfully, but these errors were encountered:
Feature Requested
It would be nice if users who were using
argcomplete
in a virtualenv could get the benefits ofactivate-global-python-argcomplete
without having their global shell configuration files modified. That is, without modifying~/.zshrc
,~/.bash_completion
, or any other file used in a context outside of the existingvirtualenv
(or at the very least, without having these global files reference/source files in the virtualenv)Motivation
Virtualenv's are frequently non-permanent environments that live on users systems; it is common for them to be destroyed, recreated, etc. This is especially true for developers who might spin one up per-project and may reinstall it every time their python version increases.
Currently,
activate-global-python-argcomplete
modifies both~/.zshrc
,~/.bash_completion
, having them source files within these transitory environments. This leads to multiple problems, 3 such problems are:These files may not exist if these transitory environments were removed, any security implications about sourcing files that do not exist but could be created aside, this could lead to unexpected consequences; for example, someone might deletes their
test
virtualenv then recreate it yet not runactivate-global-python-argcomplete
; but due to the previousactivate-global-python-argcomplete
run the autocompletions files might be sourced if the paths happen to be the same. This isn't likely a catastrophic danger or anything, but I'd argue it's someone counter to how virtualenvs are generally expected to behaveThese completions may be undesired outside of the virtualenv. A user might not command completions to activate on a given command when not using said command in the virtualenv. This could be for multiple reasons, but one obvious one is just to reduce the amount of unnecessary shell code that runs on shell startup.
Duplicate code. If a user has multiple virtualenvs each with argcomplete installed via
activate-global-python-argcomplete
, each one of those would be loaded on shell login. I'm not sure if this has other side effects.Solutions
I am not quite sure what a good solution for this would be, but I can think of a few things:
activate-global-python-argcomplete
can either detect if it's in a virtualenv and respond accordingly, prompt the user, or anactivate-virtualenv-python-argcomplete
command can be providedactivate-virtualenv-python-argcomplete
can append to:/home/me/.virtualenv/my_venv/bin/activate
something like the following:activate-virtualenv-python-argcomplete
can prompt the user asking where this should be writtenactivate-global-python-argcomplete
could install it's config files outside of thevirtualenv
(if they will work for all virtualenvs). At that point, it could either be that it activates for all argcompletes in all virtualenvs and the global space, or it have it check the current ENV to determine if it is in a virtualenv that activated locally- either is a solution though both obviously have tradeoffs.The text was updated successfully, but these errors were encountered: