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

Feature Request: activate-virtualenv-python-argcomplete #511

Open
zwimer opened this issue Oct 28, 2024 · 0 comments
Open

Feature Request: activate-virtualenv-python-argcomplete #511

zwimer opened this issue Oct 28, 2024 · 0 comments

Comments

@zwimer
Copy link

zwimer commented Oct 28, 2024

Feature Requested

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:

  1. 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

  2. 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.

  3. 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 zsh
elif [ -n "$BASH_VERSION" ]; then
    source /path/to/completions
    reload-completions   # However this is done in bash
fi
  • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant