Add functions and "snippets" hierarchy #2498
Conversation
This allows "vendors" (i.e. third-party upstreams interested in supporting fish) to add auto-loaded functions and eager-loaded "snippets", while still allowing both the user and the administrator to fully override all of that. This has been inspired by systemd's configuration hierarchy. Fixes fish-shell#1956
|
Currently this doesn't work because $XDG_CONFIG_HOME isn't defined in config.fish yet - any idea what we should do? |
|
Maybe use something like others app would do:
|
That's actually the behavior documented in the spec. I was confused because I assumed we'd inherit an XDG_CONFIG_HOME, but if we did it would already be defined. |
|
Looks good to me. Maybe fish should set all XDG envs? because if it's started as shell after login on TTY there won't be anything that sets them. |
|
Turns out we already did the "XDG_CONFIG_HOME or ~/.config" dance above - though only locally. But this isn't the place to define XDG__ always (that'd be a separate PR and discussion) or make a "$__fish_userconfdir" global variable (like "$__fish_sysconfdir"). |
|
this is really good here. It'd be nice to be able to boot with an empty /etc/ but still have be able to use vendor provided fish config , instead of relying in /etc/fish |
|
$_fish_sysconfdir sounds reasonable. I wouldn't mind if the XDG* vars were set by fish (if not previously set) though! |
|
I don't think fish should set the XDG variables; my reading of the XDG spec suggests that we would be responsible for maintaining them including checking permissions and maintaining a lifecycle, which I don't think is fish's role. I think it's reasonable to set |
|
@faho, this looks good. At the risk of bikeshedding, I think It will definitely need noting in the documentation. r+ zanchey@ with the |
| # As last part of initialization, source the snippets directories | ||
| # Implement precedence (User > Admin > Vendors > Fish) by basically doing "basename" | ||
| set -l sourcelist | ||
| for file in $configdir/fish/snippets/* $__fish_sysconfdir/snippets/* $__fish_datadir/vendor_snippets.d/* |
There was a problem hiding this comment.
This is pretty clever, but we'll have to watch the case where those wildcards expand to nothing once #2394 is changed.
faho
added
docs
|
This looks sensible to me, but I think I slightly prefer "conf.d" over "vendor-snippets.d". |
|
@amluto: Just "conf.d" or "vendor-conf.d"? I think the latter'd have a nice symmetry with "completions"/"vendor-completions.d". |
|
If it weren't for all the others, I'd say just "conf.d". But "vendor-conf.d" would be fine, too. |
Seems more intuitive. Also more consistent with the ".d" prefix.
|
Looks good to me. Is there anything that moves /etc/fish/config.fish into /usr/share? If not, I can do it in the Fedora package. |
|
There won't be, no - I think that's best left to the packaging infrastructure as it will require superuser permissions and won't work well either in fish launch or the Makefile. |
|
@amluto, @zanchey: How about appending everything in etc/config.fish to share/config.fish (which seems to be the same order we currently have) and then removing it entirely? $__fish_sysconfdir/config.fish would still be available, only not installed by default. Or moving it to conf.d would be fine, that would keep it overrideable. Though I don't quite like that file - is /etc/sysconfig/i18n still a thing? That's a Fedora-ism IIRC, and you guys switched over to systemd's locale.conf a while ago. (It also contains a useless-use-of-cat, and a use of |
|
I'm fine with either option.
|
It's a bit tough to find the balance between giving packagers and third-party programmers good information but not overwhelming the casual user.
|
I have no clue about /etc/sysconfig/i18n. I could ask around, I guess.
|
|
@zanchey: Merge at your discretion - I can't see anything missing. |
| # As last part of initialization, source the conf directories | ||
| # Implement precedence (User > Admin > Vendors > Fish) by basically doing "basename" | ||
| set -l sourcelist | ||
| for file in $configdir/fish/conf.d/* $__fish_sysconfdir/conf.d/* $__fish_datadir/vendor_conf.d/* |
There was a problem hiding this comment.
shouldn't $__fish_sysconfdir/conf.d itself be allowed to not exist? and all of $__fish_sysconfdir for that matter. I've been experimenting with empty /etc (stateless systems), and this seems like it would break that.
There was a problem hiding this comment.
@jrobeson: This actually works in that case because the glob currently expands to nothing (try echo /arglbargl/* in a script - interactively it'll warn, but in a script it'll work). With #2719 as solution to #2394 it will continue to work. Yes, if we go with something else it might need to be revisited.
|
If there are no further comments, I intend to merge this in a week. |
|
Please correct me if I am wrong, I am trying to understand exactly what these changes mean. So, I see users will be able to add their own "initialization" code to But other than that, I am not sure what you mean by eager-loaded "snippets" and how, if at all, this affects what functions are autoloaded. |
Those are the files in conf.d. They can of course affect what functions are autoloaded - they are full fish scripts that are just sourced, after all, so they could e.g. alter fish_function_path. You'll want to be careful with these, but if anyone writing these snippets screws up, it's easy enough to override and report a bug to them. |
|
@faho Sure. But what I mean is: other than these new "initialization" files is there anything else I should know about the upcoming changes that I may be missing? I was just confused of what you meant by "snippets" as I prefer to think of them a "initialization" files, but maybe that's just me. |
@bucaran: This touches three kinds of files:
The change for functions is rather trivial: There's now an additional directory for third-party (i.e. neither fish nor the user) "vendor functions", just like the one for vendor completions. I'm not sure if it'll be useful to you as it'll be system-wide and most likely root-owned. These are useful for other programs, especially those installed via package manager. "Snippets" are introduced here - these are fish scripts that are supposed to be sourced. Like functions and completions, there are four directories for the user, administrator, third-parties and fish, respectively. And also like functions and completions, for every filename, fish will only (attempt to) read the first one that exists. If you have files with the same name in the user and the administrator directories, the user wins. The main use-case for these was something like pantheon-terminal, which supports completion notifications via dbus - see #1382. |
|
Gotcha. So, what's up with |
|
Not my terminology - it's called that in systemd, xorg and potentially other places, with roughly the same semantics. |
|
Good to know and thanks 👍 |
|
Some more history is at https://lists.debian.org/debian-devel/2010/04/msg00352.html. I think fragments is better than snippets but taking precedent from systemd seems reasonable #bikeshed |
|
Fragments? I am really glad we're going with |
|
Merged as c1b384e. Thanks for all the comments! |
ghost
mentioned this pull request
This allows "vendors" (i.e. third-party upstreams interested in
supporting fish) to add auto-loaded functions and eager-loaded
"snippets", while still allowing both the user and the administrator to
fully override all of that.
This has been inspired by systemd's configuration hierarchy.
Fixes #1956
This is a slightly-less-quick alternative to #2496. It's probably not ready (the terms aren't final either), it's just meant to get the conversation going again.