Userscripts are unavailable during qutebrowser sessions

[stooj]

Qutebrowser userscripts are stored in $XDG_DATA_HOME/qutebrowser/userscripts, so are unavailable when using your (awesome) wrapper script.

Here's a patch that works for me, by symlinking the userscripts directory into the session dir.

diff --git a/bin/qutebrowser b/bin/qutebrowser
index 942609f..f1ca8fc 100755
--- a/bin/qutebrowser
+++ b/bin/qutebrowser
@@ -69,6 +69,10 @@ if [ $basedir_specified -eq $FALSE ]; then
 	ln -fsT "$XDG_CONFIG_HOME/qutebrowser" "$basedir/config"
 	ln -fsT "$XDG_CACHE_HOME/qutebrowser/$session" "$basedir/cache"
 	ln -fsT "$XDG_DATA_HOME/qutebrowser/$session" "$basedir/data"
+	if [ -e "$XDG_DATA_HOME/qutebrowser/userscripts" ]; then
+		ln -fsT "$XDG_DATA_HOME/qutebrowser/userscripts" \
+			"$XDG_DATA_HOME/qutebrowser/$session/userscripts"
+	fi
 fi
 
 # Search "real" qutebrowser executable:

[ayekat]

Hey, thanks for pointing that out! I missed this because I don't use userscripts myself (yet).

This is a bit of a tricky issue, though. The XDG basedir spec doesn't distinguish between "static" data (the equivalent of /usr/share or even /usr/lib in the FHS) and state data (the equivalent of /var/lib). So far, I have treated XDG_DATA_HOME as a state data directory (because most applications create and manage data in there on their own). This is also true for qutebrowser, where I don't touch anything in its data directory, as I consider it to be application state (and so I create distinct state directories for each instance).

Now, qutebrowser userscripts are tricky in that they are not really state data, but static data that can and should be shared across all sessions, similar to the config directory (qutebrowser doesn't appear to manage userscripts on its own, but simply expects users to place them there). I would thus personally rather not place them in XDG_DATA_HOME, as that would be semantically weird.

(another issue is what happens if someone starts a session called "userscripts": the associated state/data would be placed in XDG_DATA_HOME/qutebrowser/userscripts, and we'd have quite a bit of a mess there)

Personally, I'd like the XDG basedir spec to be extended with something like an XDG_STATE_HOME variable (and applications putting most of their stuff in there), so that XDG_DATA_HOME can be considered the right place to put in static data like qutebrowser userscripts. But that is sadly utopic, because proposals for extending/fixing the spec have been around for several years now, and nothing has ever really been done so far.

A realistic (yet still a bit hacky) way to solve this for now is probably to expect userscripts to reside in XDG_CONFIG_HOME/qutebrowser/userscripts, together with all the other user-defined data (and having the symlink pointing there instead).

[stooj]

Yep, that makes sense. I used $XDG_DATA_HOME/qutebrowser/userscripts as the path to check because that's where qutebrowser expects them by default. (See qutebrowser/userscripts.asciidoc at master · qutebrowser/qutebrowser)

Extract from those docs:

To call a userscript, it needs to be stored in your data directory under userscripts (for example: ~/.local/share/qutebrowser/userscripts/myscript), or just use an absolute path.

Perhaps the best bet is to configure my qutebrowser config with an absolute path to my userscripts, and not bother about symlinking them at all.

[ayekat]

I honestly don't know what the best approach would be. For one, I'm a bit reluctant to just stubbornly symlink it to XDG_CONFIG_HOME/qutebrowser/userscripts right now, since I'd rather avoid changing the behaviour of my script too much from what "vanilla" qutebrowser users expect. And as explained above, the default behaviour of expecting userscripts in XDG_DATA_HOME/qutebrowser/userscripts is messy.

To be honest, I would love to hear The-Compiler's opinion about his stance on the "static vs. state data" issue, but AFAIK he's a bit busy these days, so I'll wait until the end of the semester at least.

[ayekat]

Alright, I've changed the qutebrowser script as follows:

[2a4822c] XDG_STATE_HOME

Session data is now expected to reside in $XDG_STATE_HOME/qutebrowser/{session}. Note that XDG_STATE_HOME is not part of the official XDG base directory specification, so there exist multiple rogue implementations for this variable, two notable ones being:

• XDG_STATE_HOME defaults to ~/.local/state: While this appears to be the more often mentioned one, I don't consider this to be very consistent; I believe ~/.local represents the equivalent to the FHS's /usr (or /usr/local) tree, which should be considered immutable for applications; state, cache and log data typically goes into /var, which is a different tree.
• XDG_STATE_HOME defaults to ~/.var/state: This is the less popular one, but IMHO more consistent. It was made by Allison Lortie here. It would also allow a potential—albeit unlikely—future change of XDG_CACHE_HOME's default to something like ~/.var/cache).

As you may see from the commit, I went with the second implementation (~/.var/state).

Essentially, though:
WARNING: Using the new script will require you to manually move all data from $XDG_DATA_HOME/qutebrowser into $XDG_STATE_HOME/qutebrowser (or ~/.var/state/qutebrowser if XDG_STATE_HOME is not set).

[092d410] userscripts

The userscripts directory is linked in from $XDG_DATA_HOME/qutebrowser/userscripts as you proposed. Since I don't use any userscripts yet, I can't test if this works properly, so it would be nice if I could get some feedback :-)