kislyuk
commented
1 year ago Thanks for writing this up, you have a lot of good insights and you point out some real ergonomics problems with the package. I agree the docs should be updated to clarify the difference between operating argcomplete as root vs. as the user. The package does not install anything outside its installation directory in the course of initial installation; as you correctly pointed out this is because packages are generally not expected to do this, and violating the "principle of least surprise" in this way can cause a variety of issues, including a failure to install the package and its reverse dependencies altogether.
The pre-dynamic loading bash-completion directory is used because unfortunately, there is no way to hook a complete -D script into the bash-completion 2.0 infrastructure, and that is required for global completion activation. If the directory does not exist, the installation script prints a message asking the user to troubleshoot this, but I agree it could be made clearer that the directory needs to be created. We could, in theory, look into switching targeted argcomplete activation (register-python-argcomplete) to use the bash-completion 2.0 framework.
The internal tool is not documented because it's internal :)
You bring up other good points - this is just to acknowledge and thank you for that and to request patience - it may take me a while longer to get to addressing this. PRs are welcome.
flu0r1ne
I was aiming to setup install hooks to automatically register completion scripts during the pip install. I don't know if there was a design decision to explicitly avoid this pattern. (E.g. this modifies files outside of the purview of pip and should be managed by the distribution or the end user.)
Regardless, I first started with the more basic task of getting global registration to work reliably. I haven't been successful, but I wanted to share some insights:
pipdrops it into~/.local/bin/. Of course, you cannot runactivate-global-python-argcompleteas root since it won't be found in the path. (Neither should you since the script will not be able to find theargcompletemodule.) Thus, the default instructions will not work for these users:Instead, you need to install the package globally or preferentially install it with your system's package manage. I think the recommendation here would be "set up local completion" or "consult your distro's package manager." Some distro's versions are outdated and I couldn't find any documentation regarding potential incompatibilities of versions 2.x and 3.x. Are client programs written for 3.x compatible with the global registration scripts written by the 2.x version?
/etc/bash_completion.dseems to be outdated. Ubuntu seems to have deprecated it.archdid not have it.Quoting from the bash-completion documentation:
Now, they recommend scripts be installed in
/usr/share/bash-completion/bash_completion. I don't know if this is an intentional "early-loading" bypass. If not, it might be best to change the default location. If so, it might be best to add a note to the documentation and create/etc/bash_completion.dif it does not exist.python -m argcomplete._check_console_script "$(which app)"useful for determining ifargcompleteis able to find thePYTHON_ARGCOMPLETE_OKtag. This isn't documented. It seems thatpython-argcomplete-check-easy-install-scriptis still installed by default. This is misleading because it seems that thepipreplacement for easy install does not insert theEASY-INSTALL-SCRIPTmarkers. Thus, it produces a false negative.I would be happy to work with you to update the documentation or install scripts if needed!