cli
cli copied to clipboard
httpie
fish shell completions
It would be amazing if httpie could default-install completions for the awesome fish shell.
Reference: https://fishshell.com/docs/current/#where-to-put-completions
Example of other great tools that does this:
ll /usr/share/fish/vendor_completions.d
.rw-r--r-- 4.4k root root 25 Apr 13:48 bat.fish
.rw-r--r-- 51k root root 11 Mar 2:24 docker.fish
.rw-r--r-- 12k root root 9 May 17:38 rg.fish
I see the problem here that httpie is not really responsible for the installation process. This is done by the package maintainers of your Linux distribution (if you installed from the repositories as advised in the README).
Hence, a packaging request would need to be filed at the respective distribution's issue tracker.
For example, I filed a request for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1834441
Is there really no way for httpie to add to what is unpacked in the installation process, and default-including the completions file?
Edit: I see now that the completion does exist here https://github.com/jakubroztocil/httpie/blob/master/extras/httpie-completion.fish - but it still seems very inefficient to have to request this to be installed by every distribution.
I would also say that the request you made should be updated. For the fish shell, the default should be to install them into XDG_DATA_DIRS and only secondly try /usr/share/fish/vendor_completions.d/.
I guess having a packaging guide of sorts would make it easier for maintainers to produce better packages.
The only kind-of-official non-PyPi package is the Homebew formula, and I now realise that not even there the completions get installed.
I assume that there’s no reliable way to install the *shell completions with pip.
@exploide thanks for the Fedora request 👍
I would also say that the request you made should be updated. For the fish shell, the default should be to install them into XDG_DATA_DIRS and only secondly try /usr/share/fish/vendor_completions.d/.
You mean a XDG_DATA_DIRS that contains a (different) system-wide directory? The package maintainers know where these paths are in their distribution and how to retrieve them. When bulding the package, for example using Fedora spec files, they would use %{_datadir} as a variable that points to the correct directory. We don't need to tell them and it will almost always be /usr/share anyways.
Is there really no way for httpie to add to what is unpacked in the installation process, and default-including the completions file?
it still seems very inefficient to have to request this to be installed by every distribution.
Depends on what you mean with installation process. One can install httpie via different means. If you use your Linux distribution's package management, then it's up to them. httpie is not involved in the packaging process. That's how it works.
I guess having a packaging guide of sorts would make it easier for maintainers to produce better packages.
That could be helpful. Some projects even maintain the spec file for RPM and whatever is needed for DEB packages in their repository. But distro maintainers would need to pick that up and coordinating effort would be necessary. Don't know how feasible that is right now.
I assume that there’s no reliable way to install the *shell completions with pip.
In theory, setup.py could install it because it can run arbitrary code. But this is enormously uncommon I think. Don't know if the Python Packaging Authority has a statement concerning that. But I can imagine that becomes horrible. Where to install the file in which case, what about virtualenv and for uninstalling there is no way?!
The only kind-of-official non-PyPi package is the Homebew formula
While I have literally no experience with MacOS X and Homebrew, I think I have read something about homebrew packages installing autocompletion files somehow.
Ok, I did not know it was this involved. Reading the repos of other tools such as fd, hyperfine, bat etc. I could not find anything related to that they had to request this from package maintainers, but not saying they haven't. We all learn something new every day 😄
Additionally, things become different for other programming languages and environments. The Rust tool fd for example generates the completion files automatically using Clap. The fd project then creates own deb packages with its CI system. This deb will of course contain the autocompletion files. But there is no guarantee Debian, Ubuntu and the others produce the package the same way. On the other hand, rpm packages are not produced by fd's CI. Fedora maintains the necessary spec file by its own and incorporates the completion files there explicitly.
Packaging is a mess :roll_eyes:
PS: It is not always necessary to request that from package maintainers. Often they find the files by themselves within the source and include them. But they are all human beings and some don't care initially about shell completions and some others have no idea what the heck fish is :smile:
Fish core developer here.
We are always happy to upstream completions directly into the fish codebase, if you like. Fish ships with hundreds of hand-written "dynamic" completions that go far beyond merely state-machine-based deduction of autocompletion parameters and can provide "dynamic" logic based on introspecting the command line and even executing commands at runtime (e.g. the aws s3 completions allow you tab-complete s3 paths by executing s3 ls and parsing the results incrementally).
Oh yes, apparently I forgot to mention this option despite I recently contributed completions to fish by myself :smile:
So if the httpie project would like to hand over the completion file to fish itself, that would make things more seamless for fish users.
A possible drawback to note: It can then happen that the installed version of httpie is not in sync with the file installed with the version of fish. Users could see outdated or missing options from the completion. Don't know if this is negligible since currently most fish users have no httpie completions at all (despite the autogenerated ones).
Thanks for dropping in, @mqudsi! Including the completions in the fish codebase would indeed be the most robust solution. @exploide’s note about the possible version mismatch is valid, though—is there a standard way of dealing with that, e.g., by supporting multiple versions of the command being autocompleted simultaneously?
is there a standard way of dealing with that, e.g., by supporting multiple versions of the command being autocompleted simultaneously?
I would not call that a standard way but yes. Some completion files that suffer the same problem try to solve that by checking --version and offer some options only when appropriate.
I’m playing with idea of providing a built-in API for the shell completions (maybe using something like @kislyuk’s https://github.com/kislyuk/argcomplete). Then the shell-specific completions scripts could be pretty minimal and hopefully version agnostic.