Attribute for plugin-managed data

[detly]

I was contemplating writing a more structured dconf plugin based on the notes/examples around the place. One speedbump I've hit is how exactly to store the data.

If I store it in the source dir, chezmoi will try to populate it in the user's directory. So if I do eg. $SRC_DIR/dot_dconf-plugin, the user ends up with ~/.dconf-plugin. But I don't want this, the point is the store the data and then load it with the dconf command line utility. It doesn't need to go through some intermediate filesystem tree.

One workaround is to simply accept this and have my plugin use files in eg. ~/.config/dconf-plugin. But then a plugin is not really solving anything. A user can already run dconf load on stuff stored in chezmoi. I'd basically be writing a non-chezmoi application that reads data from yet another config dir. The real problem I want to solve is managing the gap between dconf dump output and chezmoi's structured storage.

What I would (tentatively) suggest is a new source state attribute, plugin_, where chezmoi does not populate targets based on such a directory, and does not (by default) overwrite them on add.

There may be other useful features you could do with this, eg. a special .chezmoiplugin file containing a plugin name, so that chezmoi commands are passed through to the plugin (chezmoi apply invokes chezmoi pluginname apply <temp path to post-template-rendering source subtree> or somesuch). But primarily, having a way to store data without applying directly would be good. I haven't been using chezmoi for that long, so maybe there's a way to do this with the existing features I haven't seen yet.

[detly]

Oh, as a side note — the docs aren't super clear on what environment variables a plugin will see. Are they the same as for hooks and scripts? Is there a way to get the source and target directory without hard-coding?

[twpayne]

What I would (tentatively) suggest is a new source state attribute, plugin_, where chezmoi does not populate targets based on such a directory, and does not (by default) overwrite them on add.

chezmoi ignores all files that begin with a . in the source directory (except for .chezmoi* of course) so you can use $CHEZMOI_SOURCE_DIR/.dconf-plugin.

Oh, as a side note — the docs aren't super clear on what environment variables a plugin will see. Are they the same as for hooks and scripts? Is there a way to get the source and target directory without hard-coding?

To see what environment variables are set, the easiest way is to run:

$ chezmoi cd
$ set | grep ^CHEZMOI_

You can get the source directory with the chezmoi source-path command.

However, do you really need a dconf plugin for all of this? I use a run_onchange_after_ script that calls gsettings.

[detly]

Thanks for the pointers. I think someone also suggested (and then deleted the suggestion?) to use .chezmoiignore, which I think works with some caveats.

However, do you really need a dconf plugin for all of this? I use a run_onchange_after_ script that calls gsettings.

Well, the reason I became dissatisfied with this approach (which I used to use a non-chezmoi variant of) was:

• this populates the settings, but doesn't extract them to add in the first place
• it works for Gnome Terminal, given its particular Gsettings structure for profile settings' relocatable schemas, but won't work for
  • multiple profiles
  • or other applications with dynamic settings

I'd like to be able to simply do something like chezmoi dconf add /org/gnome/terminal/ and have the settings be ready to commit, and do chezmoi dconf apply /org/gnome/terminal/ on another machine to apply them. And for anything else. Don't know how viable that is yet, so I have the benefit of total optimism.

[twpayne]

Thanks for the further detail.

chezmoi supports per-command hooks that might also help here.

[bradenhilton]

Thanks for the pointers. I think someone also suggested (and then deleted the suggestion?) to use .chezmoiignore, which I think works with some caveats.

@detly That was me. I deleted the comment because it was a mistake on my part.