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

Add functions and "snippets" hierarchy #2498

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@faho
Member

faho commented Oct 20, 2015

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.

Add functions and "snippets" hierarchy
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

@faho faho referenced this pull request Oct 20, 2015

Closed

Source sys and data configs #2496

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Oct 20, 2015

Member

Currently this doesn't work because $XDG_CONFIG_HOME isn't defined in config.fish yet - any idea what we should do?

Member

faho commented Oct 20, 2015

Currently this doesn't work because $XDG_CONFIG_HOME isn't defined in config.fish yet - any idea what we should do?

@pickfire

This comment has been minimized.

Show comment
Hide comment
@pickfire

pickfire Oct 21, 2015

Contributor

Maybe use something like others app would do:

  1. Check ~/.config/*
  2. Check $XDG_CONFIG_HOME
Contributor

pickfire commented Oct 21, 2015

Maybe use something like others app would do:

  1. Check ~/.config/*
  2. Check $XDG_CONFIG_HOME
@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Oct 21, 2015

Member

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.

Member

faho commented Oct 21, 2015

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.

@davispuh

This comment has been minimized.

Show comment
Hide comment
@davispuh

davispuh Oct 21, 2015

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.

davispuh commented Oct 21, 2015

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.

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Oct 21, 2015

Member

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").

Member

faho commented Oct 21, 2015

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").

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Oct 30, 2015

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

jrobeson commented Oct 30, 2015

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

@jrobeson

This comment has been minimized.

Show comment
Hide comment
@jrobeson

jrobeson Nov 14, 2015

$_fish_sysconfdir sounds reasonable. I wouldn't mind if the XDG* vars were set by fish (if not previously set) though!

jrobeson commented Nov 14, 2015

$_fish_sysconfdir sounds reasonable. I wouldn't mind if the XDG* vars were set by fish (if not previously set) though!

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Dec 11, 2015

Member

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 $__fish_userconfdir. The reason I wasn't terribly keen on it is that if you set $XDG_CONFIG_HOME (or whatever) then the variable won't automatically be updated (though a handler could be added to do that), but then it turns out that fish doesn't actually react to changes in those variables anyway.

Member

zanchey commented Dec 11, 2015

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 $__fish_userconfdir. The reason I wasn't terribly keen on it is that if you set $XDG_CONFIG_HOME (or whatever) then the variable won't automatically be updated (though a handler could be added to do that), but then it turns out that fish doesn't actually react to changes in those variables anyway.

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Dec 11, 2015

Member

@faho, this looks good. At the risk of bikeshedding, I think conf.d is a better name than snippets.d, and is more in keeping with the way that at least Debian packages work.

It will definitely need noting in the documentation.

r+ zanchey@ with the conf.d change, although of course I would appreciate the opinion of other packagers such as @amluto.

Member

zanchey commented Dec 11, 2015

@faho, this looks good. At the risk of bikeshedding, I think conf.d is a better name than snippets.d, and is more in keeping with the way that at least Debian packages work.

It will definitely need noting in the documentation.

r+ zanchey@ with the conf.d change, although of course I would appreciate the opinion of other packagers such as @amluto.

@zanchey zanchey added this to the next-2.x milestone Dec 11, 2015

Show outdated Hide outdated share/config.fish
Show outdated Hide outdated fish.pc.in
@amluto

This comment has been minimized.

Show comment
Hide comment
@amluto

amluto Dec 11, 2015

Contributor

This looks sensible to me, but I think I slightly prefer "conf.d" over "vendor-snippets.d".

Contributor

amluto commented Dec 11, 2015

This looks sensible to me, but I think I slightly prefer "conf.d" over "vendor-snippets.d".

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Dec 11, 2015

Member

@amluto: Just "conf.d" or "vendor-conf.d"? I think the latter'd have a nice symmetry with "completions"/"vendor-completions.d".

Member

faho commented Dec 11, 2015

@amluto: Just "conf.d" or "vendor-conf.d"? I think the latter'd have a nice symmetry with "completions"/"vendor-completions.d".

@amluto

This comment has been minimized.

Show comment
Hide comment
@amluto

amluto Dec 11, 2015

Contributor

If it weren't for all the others, I'd say just "conf.d". But "vendor-conf.d" would be fine, too.

Contributor

amluto commented Dec 11, 2015

If it weren't for all the others, I'd say just "conf.d". But "vendor-conf.d" would be fine, too.

Rename "snippets" to "conf.d"
Seems more intuitive. Also more consistent with the ".d" prefix.
@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Dec 11, 2015

Member

@zanchey, @amluto: Are both of you happy now?

Member

faho commented Dec 11, 2015

@zanchey, @amluto: Are both of you happy now?

@amluto

This comment has been minimized.

Show comment
Hide comment
@amluto

amluto Dec 12, 2015

Contributor

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.

Contributor

amluto commented Dec 12, 2015

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.

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Dec 16, 2015

Member

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.

Member

zanchey commented Dec 16, 2015

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.

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Dec 16, 2015

Member

@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 sed in the startup path, which is why I'd like to remove it)

Member

faho commented Dec 16, 2015

@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 sed in the startup path, which is why I'd like to remove it)

@amluto

This comment has been minimized.

Show comment
Hide comment
@amluto

amluto Dec 17, 2015

Contributor
Contributor

amluto commented Dec 17, 2015

Add conf.d documentation
It's a bit tough to find the balance between giving packagers and
third-party programmers good information but not overwhelming the casual user.
@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Dec 17, 2015

Member

@amluto: We'll do that afterwards. How about /etc/sysconfig/i18n? Do you know of anyone still using that?

@zanchey: I've now attempted some documentation. It's probably not ideal (as noted, finding the right balance here is tough), but should explain it alright.

Member

faho commented Dec 17, 2015

@amluto: We'll do that afterwards. How about /etc/sysconfig/i18n? Do you know of anyone still using that?

@zanchey: I've now attempted some documentation. It's probably not ideal (as noted, finding the right balance here is tough), but should explain it alright.

@amluto

This comment has been minimized.

Show comment
Hide comment
@amluto

amluto Dec 17, 2015

Contributor

I have no clue about /etc/sysconfig/i18n. I could ask around, I guess.
On Dec 17, 2015 3:25 AM, "Fabian Homborg" notifications@github.com wrote:

@amluto https://github.com/amluto: We'll do that afterwards. How about
/etc/sysconfig/i18n? Do you know of anyone still using that?

@zanchey https://github.com/zanchey: I've now attempted some
documentation. It's probably not ideal (as noted, finding the right balance
here is tough), but should explain it alright.


Reply to this email directly or view it on GitHub
#2498 (comment)
.

Contributor

amluto commented Dec 17, 2015

I have no clue about /etc/sysconfig/i18n. I could ask around, I guess.
On Dec 17, 2015 3:25 AM, "Fabian Homborg" notifications@github.com wrote:

@amluto https://github.com/amluto: We'll do that afterwards. How about
/etc/sysconfig/i18n? Do you know of anyone still using that?

@zanchey https://github.com/zanchey: I've now attempted some
documentation. It's probably not ideal (as noted, finding the right balance
here is tough), but should explain it alright.


Reply to this email directly or view it on GitHub
#2498 (comment)
.

@faho faho removed the docs label Dec 29, 2015

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Dec 29, 2015

Member

@zanchey: Merge at your discretion - I can't see anything missing.

Member

faho commented Dec 29, 2015

@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/*

This comment has been minimized.

@jrobeson

jrobeson Feb 9, 2016

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.

@jrobeson

jrobeson Feb 9, 2016

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.

This comment has been minimized.

@faho

faho Feb 9, 2016

Member

@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.

@faho

faho Feb 9, 2016

Member

@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.

This comment has been minimized.

@jrobeson

jrobeson Feb 13, 2016

cool, thanks

@jrobeson
@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Feb 13, 2016

Member

If there are no further comments, I intend to merge this in a week.

Member

faho commented Feb 13, 2016

If there are no further comments, I intend to merge this in a week.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 13, 2016

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 ~/.config/fish/conf.d which fish will now run during its own initialization process.

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.

ghost commented Feb 13, 2016

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 ~/.config/fish/conf.d which fish will now run during its own initialization process.

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.

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Feb 13, 2016

Member

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.

Member

faho commented Feb 13, 2016

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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 13, 2016

@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.

ghost commented Feb 13, 2016

@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.

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Feb 13, 2016

Member

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?

@bucaran: This touches three kinds of files:

  • Functions
  • "Snippets"/"Fragments"

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.

Member

faho commented Feb 13, 2016

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?

@bucaran: This touches three kinds of files:

  • Functions
  • "Snippets"/"Fragments"

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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 13, 2016

Gotcha.

So, what's up with snippet? I am not familiar with the terminology in this context.

ghost commented Feb 13, 2016

Gotcha.

So, what's up with snippet? I am not familiar with the terminology in this context.

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Feb 13, 2016

Member

Not my terminology - it's called that in systemd, xorg and potentially other places, with roughly the same semantics.

Member

faho commented Feb 13, 2016

Not my terminology - it's called that in systemd, xorg and potentially other places, with roughly the same semantics.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 13, 2016

Good to know and thanks 👍

ghost commented Feb 13, 2016

Good to know and thanks 👍

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Feb 14, 2016

Member

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

Member

zanchey commented Feb 14, 2016

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 14, 2016

Fragments? I am really glad we're going with snippets now.

ghost commented Feb 14, 2016

Fragments? I am really glad we're going with snippets now.

@zanchey zanchey referenced this pull request Feb 25, 2016

Closed

Cut a new release #2760

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Feb 26, 2016

Member

Merged as c1b384e. Thanks for all the comments!

Member

faho commented Feb 26, 2016

Merged as c1b384e. Thanks for all the comments!

@faho faho closed this Feb 26, 2016

@faho faho referenced this pull request Mar 6, 2016

Closed

Kill etc/config.fish #2799

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Mar 26, 2016

Member

For whoever'll draft the release notes: After discussion with @zanchey, I've now (7accadc) refined this to only read .fish files.

Member

faho commented Mar 26, 2016

For whoever'll draft the release notes: After discussion with @zanchey, I've now (7accadc) refined this to only read .fish files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment