Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Clashes with gcloud bash/zsh completion _python_argcomplete()

See original GitHub issue


the _python_argcomplete() shell function defined by Google’s gcloud SDK completion is clashing with the one defined by argcomplete:

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/

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

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:5 (1 by maintainers)

github_iconTop GitHub Comments

kislyukcommented, Sep 27, 2020

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.

algorythmiccommented, Sep 10, 2020

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 file, add something like:

. <(sed -E 's/(^| )(_python_argcomplete)(\(\)| )/\1_gcloud\2\3/g' \

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Using gcloud interactive shell - Documentation
The gcloud interactive shell produces suggestions and auto-completion for any command that has a manual (man) page, including the gcloud , bq ,...
Read more >
gcloud command not found - while installing Google Cloud SDK
bashrc on its own. In my case, it was export PATH="$HOME/google-cloud-sdk/bin:$PATH" as I had installed the SDK folder in my home directory.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found