what's the proper way to package completions?

[tamird]

See https://github.com/arighi/virtme-ng/pull/181 for context.

virtme-ng wants to generate bash completion during its build, but it's not exactly clear how to do that using argcomplete. Compare this to argparse-manpage which provides instructions and library entry points to integration with build systems.

Is there any guidance available on this?

[kislyuk]

Hi, thanks for your interest in argcomplete. I tried to read the issue you linked and the statements you made, but I'm having trouble understanding the question. Generally, packages that depend on argcomplete use the package manager (pip, etc.) to specify the dependency, and then use the argcomplete protocol to generate completions at runtime. There is nothing to do at build time. I think it might help if you review how argcomplete works and reframe your question in terms of what exactly you're trying to accomplish using argcomplete.

[tamird]

I think you understood exactly right. virtme-ng isn't my project, but for better or for worse it is currently building completions at build time and packaging them in the distribution.

I'm also not sure how argcomplete can be used to generate completions at runtime in a way that's invisible to the end user - from what I can tell, the end user always has to do something to enable argcomplete in their shell.

I see two possible answers here: there is a way to generate completions transparently and virtme-ng should just do that, or else there's an unmet need for building completions ahead of time and this can be turned into a feature request in argcomplete.

What do you think?

[kislyuk]

I'm not sure what you mean by "generate completions transparently", but argcomplete is not useful or intended for building completions ahead of time. Such completions would by definition be static and you can contribute them directly to bash-completion or zsh-completions. argcomplete is intended as a general purpose dynamic completion generator. I don't think a feature request to build completions ahead of time would be fulfilled, although I'm open to considering more specific ideas.

When using an OS package manager, it's not strictly necessary for the user to explicitly enable argcomplete in their shell. An application using argcomplete could add a profile.d entry that runs eval "$(register-python-argcomplete my-python-app)". When using pip, this is strongly discouraged since by convention PyPI/pip packages should not modify the system environment outside their package.

I'm going to close this issue for now since it does not seem to indicate a problem with argcomplete.

[kislyuk]

Thinking about this more, I recall this topic coming up a few times in the past. I think at minimum I'll add a documentation section drawing the distinction between static and dynamic completions, and giving people an idea of how to install a static completion module into the existing frameworks (bash-completions and the zsh completion paths).

Also, just to clarify, for pip packages, configuring things system-wide is discouraged at install time. You could still have a command like my-python-app install-completions that would install the static completions into zsh or bash (or add the dynamic completion hook eval "$(register-python-argcomplete my-python-app)" to the user's rc file).

[tamird]

Also, just to clarify, for pip packages, configuring things system-wide is discouraged at install time. You could still have a command like my-python-app install-completions that would install the static completions into zsh or bash (or add the dynamic completion hook eval "$(register-python-argcomplete my-python-app)" to the user's rc file).

Yep, this makes sense to me. You'd be amazed how much grief I got for making virtme-ng hermetic. Whether we like it or not there are some people who are happy to make a mess of their system for the sake of convenience.

Anyway I think addressing this desire - whether in docs or otherwise - would be very good.