-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fish doesn't have /usr/local/share/fish/completions in $fish_complete_path #5029
Comments
The /usr/local/ bit is the "PREFIX" that is chosen when compiling. In your case, it is just "/usr". There is no need for the "local/" subdirectory because it's tracked by the package manager anyway. |
But let's say I, without using the system package manager, install a program that includes a fish completion script. It would need to install to /usr/local to avoid conflicts with the package manager. Even though fish was installed to /usr, completion scripts might not be able to be installed there safely. Bash and zsh both include this behavior. |
It would not. This is where that "vendor" stuff comes in. If the package wants to install completion scripts, it should use /usr/share/fish/vendor_completions.d. This can either be hard-coded (again, by the packager for the distribution) or gotten via |
The problem with that approach is while /usr is the PREFIX of fish, /usr/local is the PREFIX of the local package.
|
Sure. And if it's not, you won't want to install completions either. So then you ask the user to put it somewhere in $fish_complete_path.
When I say "hardcoding" here, I was thinking of "hard-coded in the package build script" - by setting it as a compile-time variable or I'm sorry, but unless someone can come up with a compelling usecase (and installing half your system and not installing the other isn't one), I'm inclined to reject this as unnecessary complication. |
Here's my usecase: I have an AUR package |
I don't think this is the case. bash-completion only loads scripts from its own directory, plus from The whole idea of the vendor directories is that they can (should?) be set outside of the prefix - Homebrew does this, for example. If fish is installed into a prefix by a package manager, then the package manager assumes it has complete knowledge of all files in the prefix, and can install extra completions into fish's directories - so distribution-compiled packages can use I've only really thought closely about this recently, and I'm tempted to change the default vendor functions/completions/snippets path to a |
|
#5822 shows that this isn't quite true - it installs ripgrep's completions there, but then we added them as well, so now the package needs to be adjusted. Though in that case they could have been using vendor_completions.d. So... how about just adding /usr/local/share/fish/vendor* always as well as the prefixed version? |
Sounds like a good solution |
OK, having thought about this today, there needs to be directories for the following things:
My feeling is that If fish is installed into another prefix by a package manager (say Some alternatives include:
(All the above applies to functions and configuration snippets as well, of course.) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Maybe I'm missing something, but couldn't |
Yeah I think the vendor dirs should be independent of Sanity check: does fish actually need to create those (empty) vendor directories?
It might makes sense to do the same - only create the directories below |
Yeah that could work - reading
|
Vendor configuration provided by third party packages is sourced first from $EXTRA_VENDOR_PATH/vendor_* and $PREFIX/share/fish/vendor_* instead of only the latter. The default for $EXTRA_VENDOR_PATH is /usr/local/share/fish:/usr/share/fish, which enables fish to source third party configuration from packages installed there, even if fish is installed with a different prefix. The directories in $EXTRA_VENDOR_PATH will not be created by (installing) fish. In particular, with this change /usr/bin/fish also uses /usr/local/share/fish/vendor_completions.d, and /usr/local/bin/fish also uses /usr/share/fish/vendor_completions.d Fixes fish-shell#5029
Vendor configuration provided by third party packages is sourced first from $EXTRA_VENDOR_PATH/vendor_* and $PREFIX/share/fish/vendor_* instead of only the latter. The default for $EXTRA_VENDOR_PATH is /usr/local/share/fish:/usr/share/fish, which enables fish to source third party configuration from packages installed there, even if fish is installed with a different prefix. The directories in $EXTRA_VENDOR_PATH will not be created by (installing) fish. In particular, with this change /usr/bin/fish also uses /usr/local/share/fish/vendor_completions.d, and /usr/local/bin/fish also uses /usr/share/fish/vendor_completions.d Fixes fish-shell#5029
This isn't actually fixed by what got merged in #6428. |
What we've ended up with is the machinery to support "adding a third level" as referenced in #5029 (comment). Looking at what zsh has in Arch and Debian I actually think this is reasonable, but it is proving very difficult for me to explain in the documentation! In particular the use of Although the machinery is there, by default I'll work on a PR over the next 24 hours. |
I downloaded
fish
through the default arch repos.The text was updated successfully, but these errors were encountered: