Feature Requets: Environment variable: PYTHON_ARGCOMPLETE_OK_PATHS

[zwimer]

Feature Requested

It would be nice if users could specify an environment variable to enable global argcomplete on scripts, such as PYTHON_ARGCOMPLETE_OK_PATHS="/home/me/.local/bin/foo:/home/me/.local/bin/bar"

This would be equivalent to prepending those two scripts with # PYTHON_ARGCOMPLETE_OK

Motivation

By default, argcomplete works with scripts prefixed with # PYTHON_ARGCOMPLETE_OK. This is a good feature, but often inconvenient when the controlling the exact entry point to a program is difficult. For example, pyproject.toml's project.scripts

Alternatives

1. Using # PYTHON_ARGCOMPLETE_OK. For scripts installed via pyproject.toml, if users use setuptools as their backend, they can use script-files. As mentioned here (among a few other issues):
   [question] does argcomplete also work with pip installs? #371

This solution is lacking in multiple ways, however. First, the documentation explicitly states this should be avoided. Second, when installing in, for example, a virtualenv, setuptools may prefix these scripts with a shebang like #!/home/me/.virtualenvs/dev/bin/python which is generate at install-time, not build time when the project.scripts must be.

Relying on the user to add this is bad as well, as it will be removed every time pip upgrades the package

---

2. Using eval "$(register-python-argcomplete my-python-app)". End users can either run eval "$(register-python-argcomplete my-python-app)" manually every time, add the command to their bashrc/zshrc files, or if using a virtualenv, perhaps appending that line onto virtualenv/myvenv/bin/activate.

Doing so, however, is clunky, puts a good bit of extra expectation on users, and importantly may be quite slow. eval "$(register-python-argcomplete my-python-app)" works out to be more than a few lines of code which now need to be executed during every shell login, for every tool; especially compared to

PYTHON_ARGCOMPLETE_OK_PATHS="${PYTHON_ARGCOMPLETE_OK_PATHS}:/home/me/.local/bin/foo"

---

3. Custom support for setuptools installed scripts (although this only handles the setuptools case). This seems like a viable alternative some cases, but also likely a decent time investment that might end up being difficult given there are multiple issues about supporting pip installed packages. If this is on the TODO list then maybe closing this issue is ok. If it is not, however, I would imagine implementing PYTHON_ARGCOMPLETE_OK_PATHS in the meantime would be far simpler. Whichever code scans for # PYTHON_ARGCOMPLETE_OK could just check it's environment before scanning.

Additional Benefits

This is by no means the primary motivation, but a nice benefit of this could be:

This could make it easy for users to turn on or off argcomplete for individual files / paths quickly and easily, if they wanted to, without actually modifying the code of the scripts. This could be extra useful for binaries. For example, I believe pyinstaller supports a onefile mode that includes in itself a python binary; adding and removing # PYTHON_ARGCOMPLETE_OK from the first 1000 lines of this without re-installing is not something an end-user should ever need to do. Or it might be useful to disable for an individual file if another completer already handles it for some reason, as mentioned in a few issues before such as:
#495

[zwimer]

This looks like it could be added as easily as inserting

if [[ ":${PYTHON_ARGCOMPLETE_OK_PATHS}:" == *"$file"* ]]; then
    ret=1
fi

Right here:

argcomplete/argcomplete/bash_completion.d/_python-argcomplete

Line 106 in 252d529

At least from the bash side. I did this locally and it works fine for me.

[kislyuk]

Hello, thank you for your interest in argcomplete.

The shellcode hook for argcomplete is already compatible with pyproject.toml project.scripts. As part of the process of discovering argcomplete-compatible executables, the shellcode hook runs https://github.com/kislyuk/argcomplete/blob/main/argcomplete/_check_console_script.py, which enumerates available entry points and matches the currently completed script name to the file path of the module containing the corresponding entry point. It then opens and scans the module file, looking for the PYTHON_ARGCOMPLETE_OK marker in the first kilobyte.

I have updated the project documentation to be a bit more clear that the most up to date standard is supported, not just the legacy setuptools one.

I understand you have secondary motivations for wanting this change, but so far I am not convinced that it's a good idea to add and support this new configuration channel.

[zwimer]

@kislyuk Is there something lacking about this new method of support that I could fix-up, or some viable alternative that addresses the problems described that I am missing, specifically the pip install one?

[kislyuk]

@zwimer as I discussed above, the issues that you describe with pip install are not actually issues (at least as far as I can understand them from your description). Argcomplete supports detection of argcomplete-compatible scripts via PEP 621 entry points. The other advantages that you outlined are not substantial enough for us to consider this new environment variable without strong, specific demand from the community.