gmailctl (https://github.com/mbrt/gmailctl) is a CLI tool to create and maintain Gmail filters and labels. I would like to push it to the store, however gmailctl relies on files located in the user’s home folder for its configuration. Thus the snap needs (for now) to use “classic” isolation.
What files and folders are these ? the home interface gives you access to all non-hidden files and folders of a user, the personal-files interface can be configured for specific hidden files and folders … there should be no requirement for classic for such a use case (and in fact the rules do not allow it)
Also, the tool starts the user’s editor to edit the filter rules for Gmail. This is an issue with strict confinement since it cannot open the default editor set by the user (via EDITOR) neither get the user’s configuration of any editor that might be installed in the snap. Maybe there is also a workaround that I don’t know.
regarding $EDITOR, snaps do transparently support xdg-open to open files with unconfined apps outside of their confinemet.
you could try to set EDITOR to xdg-open in the environment of your app in snapcraft.yaml, that would then (hopefully) hand the file path to xdg-open outside of the confinement, which in turn should run whatever application was defined for the mime-type of the file (an editor for txt files hopefully )
Also, I found an other issue. The tool copies the file to /tmp for editing, but xdg-open seems to have trouble opening files there and I don’t understand why:
snap run --shell gmailctl -c 'xdg-open /tmp/gmailctl-2323.jsonnet'
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
user-open error: request declined by the user (code 2)
Also I’m worried that all of this might not work in the end since xdg-open returns as soon as the editor is started while gmailctl expects the file to be edited when the command returns.
With regards to /tmp it is expected that trying to open these files outside the snap is failing, because the snap (each snap) has a separate /tmp directory (actually a subdirectory inside the host’s /tmp but is mapped to /tmp inside the Snap’s world view).
But this is not the issue here. The file was created from within the snap. This is not about sharing the /tmp folder with the host, just to edit a file that was created in the /tmp folder of the snap within the container itself.
This is not about sharing the /tmp folder with the host
I think it reduces to exactly that. Within the snap’s confinement you create a temp file in that snap’s /tmp.
But xdg-open runs outside the confinement, so it can’t see within it, at least not at the same path. I doubt this usage is considered correct, but you’d need to give xdg-open an argument like this:
does the app by chance respect the $TMPDIR variable (it really should) ? you could set $TMPDIR in your environment and point it to i.e. $SNAP_USER_DATA (which will be $HOME/snap/gmailctl/current/)
Sou could try bundle an editor like nano into the snap explicitly and rely on the bundled nano
You could add a “press enter to continue” type message
You could consider using a tool like inotifywait to identify when the file has changed and block until it has, or recreate similar functionality by analysing the timestamps on the file yourself
This works without having to modify the CLI, which is good. However, it would force the user to use a single given editor without the ability to modify it. Also the user wouldn’t get its local configuration for this editor. For example, the first thing I did after installing gmailctl was to get a vim plugin for jsonnet files. I am uncomfortable with this solution because I would personally prefer to install the CLI using go get rather than snap install (and thus loose all the security/update features) if I had to use “bare” nano to edit the files.
This would make the workflow less user friendly. I presume the CLI could detect the snap environment (via env var for example) and restrict this behaviour to it. However, this makes the code depend on the platform it’s running on.
I think that doesn’t work as the user could save part of the file while still working on it. I’m also afraid it could break cross-platform compatibility with non-linux environments.
you wouldn’t have to hack your tool, but have EDITOR point to a script you ship … that in turn calls xdg-open, you can then put all the logic in there …
Re 1)
It is unfortunate but does open the option for you to bundle plugins that you think are relevant as well, though I’m not sure how easy that is.
Re 2)
You’d be able to check for the $SNAP variable amongst others to detect when you’re running in a snap,
Re 2/3)
While the user could save the file partway during editing it, the user could be using an editor that might return an exit early (for example, by adding a tab to an existing process and blocking attempt to spawn a new process), or might have some niche behaviour of going minimising to task tray / opening daemons / etc that otherwise block it from returning. Practically I’m unsure how common it might be for your user demographic, but I imagine it exists already. Asking explicitly might be the only real way of knowing they’re done.
Ultimately I think this might be the snap version of Turings Halting Problem, and there’s no “good” solution.