Clashes with gcloud bash/zsh completion _python_argcomplete()

Hi,

the _python_argcomplete() shell function defined by Google’s gcloud SDK completion is clashing with the one defined by argcomplete: https://issuetracker.google.com/issues/147687442#comment12

A work-around is to patch the gcloud defined function to suffix it and avoid the clash, but that needs to be done on each update:

sudo sed -i.orig 's/_python_argcomplete/_python_argcomplete_gcloud/g' /usr/lib/google-cloud-sdk/completion.bash.inc

I’m basically looking for alternative solutions to definitively fix the issue. Any ideas?

[kislyuk]

On the face of it, this does not look like a bug in argcomplete. If I understand correctly, gcloud vendors argcomplete and ends up forcing its argcomplete installation on the rest of the system. The bash namespace is global, and we have to accept any interference from other software stomping on our names or incorrectly vendoring us and causing interference between different vendored and unvendored versions of ourselves. Perhaps the solution here is to provide an argcomplete vendoring guide, but I’m not entirely sure what we’d write there.

The solution proposed here and in #320 does not accomplish the goal of namespace isolation either between completion targets or between argcomplete versions (there are still other functions defined in the shellcode - __python_argcomplete_run and __python_argcomplete_run_inner - that share the global namespace).

I’m not at all convinced that isolating between completion targets by creating one completion function per target is the right thing to do (it seems wasteful to load all these different functions into memory if there are a lot of targets).

I am more amenable to isolating between argcomplete versions. Imagining how this would work, ALL shell functions defined by argcomplete would need to have, in their name, the version of argcomplete that installed them (for example, __python_argcomplete_1_2_3_run (and might also possibly need to include the name and/or path to the Python interpreter that installed them).

But I’m not sure if that’s necessary or advisable either. I can imagine the solution above causing dependency hell types of issues and broken installations with cryptic errors when someone installs a bunch of completion shellcode and then upgrades Python or argcomplete.

I’d look for guidance to other software that has to deal with global namespacing in shellcode, including other bash-completion modules. I would welcome any pointers on how they deal with this kind of situation, if at all.

I’m closing this bug and PR for now. If you want an update to be considered here, please provide a clear design rationale and background on why it’s needed, how it will prevent a problem like this from reoccurring in the future, how it will behave when many completion targets are registered, and how it will behave when Python or argcomplete are upgraded.

[algorythmic]

The fault here is definitely Google’s but for a workaround that you do not have to re-apply after an update, run the sed while sourcing the file.

i.e. in your bashrc, instead of sourcing the completion.bash.inc file, add something like:

. <(sed -E 's/(^| )(_python_argcomplete)(\(\)| )/\1_gcloud\2\3/g' \
    /usr/lib/google-cloud-sdk/completion.bash.inc)

If Google ever fixes the issue by adding their own prefix/suffix to the function name, the sed above should become a no-op so it won’t break.