Personal-files request for stimmtausch

Hi all. I’m working on snapping stimmtausch (github), which requires access to a few personal files for the user:

  • $HOME/.strc - a config file
  • $HOME/.config/stimmtausch - a config directory
  • $HOME/.local/log/stimmtausch - a logging directory
  • $HOME/.local/share/stimmtausch - a directory where named pipes are stored.

As these are which are also accessed by ancillary projects such as stimmtausch.vim, I do not believe that they are a good fit for $SNAP_USER_DATA

Please let me know if you need any further information on these.

The snap is currently using:

plugs:
  config-files:
    interface: personal-files
    read:
      - $HOME/.strc
      - $HOME/.config/stimmtausch
  share-files:
    interface: personal-files
    write:
      - $HOME/.local/share/stimmtausch
  log-files:
    interface: personal-files
    write:
      - $HOME/.local/log/stimmtausch

Your case for not usng SNAP_USER_DATA makes some sense, but I can say that you should be able to have vim conditionally use $SNAP_USER_DATA/... through the ‘current’ symlink and fallback to $HOME. Can you comment why this doesn’t work for you?

As it stands, your snap is the clear owner of $HOME/.config/stimmtausch and $HOME/.local/share/stimmtausch, but $HOME/.strc is less clear and $HOME/.local/log/stimmtausch won’t work well since $HOME/.local/log/ is non-standard, not guaranteed to exist and your snap won’t have the permissions to create it.

Furthermore, the personal-files interface is most typically used for imported existing configuration and not for writing since a snap and its distro-packaged or locally-installed application may not be backward and forward compatible with the configuration files and data.

Since several requests are made in this topic and I made several points, I’ll ask a few questions to guide the conversation:

  1. Can you comment why using SNAP_USER_DATA through the current symlink (eg, ~/snap/ stimmtausch/current doesn’t work for you with vim?
  2. What is the relationship of $HOME/.strc to your snap? (Eg, please provide a link to a doc if your snap is the owner)
  3. It seems like putting logs in SNAP_USER_DATA would be most appropriate. Can you comment?
  4. If only named pipes are in $HOME/.local/share/stimmtausch, it seems like SNAP_USER_DATA or SNAP_USER_COMMON would be most appropriate. Can you comment?
  5. If you have existing users that are migrating to the snap, would read-only access to $HOME/.config/stimmtausch and $HOME/.local/log/stimmtausch (and possibly $HOME/.strc depending on the answer to ‘2’) via personal-files be sufficient for you to copy these into SNAP_USER_DATA/SNAP_USER_COMMON?

Thanks for such a thorough response! My base concern here boils down to the fact that the snap is not the only way for the user to install Stimmtausch. Not only is there a .deb, but updating via go install is the current way to get e.g: nightlies at this point. In both these instances, making a SNAP_USER_DATA by hand (if one is not using snaps) feels like a weird ask.

One solution, now that I think about it, is to check if SNAP_USER_DATA is set (which I believe it is in the VM) from within Stimmtausch and, if so, rely on that for logs and named pipes. If not, it can then check for the current set of .local files. The snap install of Stimmtausch, on trying to access local files, would just get a permission denied, and I think that’s reasonable.That solves #1, #3, and #4

Let me address each point.

  1. Solved - Check for SNAP_USER_DATA. It would be relatively rare to use both the vim plugin and Stimmtausch in different ways on different computers, so I feel it’s fair to ask the user to just go along with this.
  2. Solved - I can just remove this requirement, honestly. Stimmtausch is intended to be a modern replacement for TinyFugue which uses a ~/.tfrc file as the only config file it loads by default, which then has the ability to load other files. Since Stimmtausch knows to load everything in ~/.config/stimmtausch without a single file pulling them all together, I’m alright with just getting rid of this and asking users to migrate to something like ~/.config/stimmtausch/base.yaml.
  3. Solved - Check for SNAP_USER_COMMON - having the logs in a consistent place across revisions is important, and those are write-only.
  4. Solved - Check for SNAP_USER_DATA
  5. Question - I would still like access to $HOME/.config/stimmtausch for the reasons mentioned in the first paragraph: having a consistent location for configuration files makes sense for software that can be installed via more than one mechanism. Additionally, as these are the only files that the user will be editing by hand, having them in a location that is used by other programs by convention seems right. That leads to the following configuration for personal files:
plugs:
  config-files:
    interface: personal-files
    read:
      - $HOME/.config/stimmtausch

Does this seem like a reasonable solution?

With the snap being the clear owner of this directory and only requested read-only access, this is totally fine. For this to be consistent with how personal-files is used elsewhere, please use this instead:

plugs:
  dot-config-stimmtausch:
    interface: personal-files
    read:
      - $HOME/.config/stimmtausch

+1 for use and auto-connect of personal-files for read-only access to $HOME/.config/stimmtausch using the dot-config-stimmtausch interface reference. @reviewers - can others please vote on (only) this use of personal-files?

1 Like

Thanks for the help. Will land https://github.com/makyo/stimmtausch/pull/95/files#diff-5fde7a6d86053f0e1d88c0a2a238941f once I have confirmation.

+1 from me also for use and auto-connect of personal-files for read-only access to $HOME/.config/stimmtausch using the dot-config-stimmtausch interface name

+1 for the use and auto-connection of personal-files for read-only access to $HOME/.config/stimmtausch.

3 votes for, 0 against for for read-only access to $HOME/.config/stimmtausch using the dot-config-stimmtausch interface reference. Granted. This is now live.

@Makyo - there is a corresponding change to the review-tools that is not in production yet. In the meantime, you can request manual review for new revisions and a reviewer will perform the approval manually.

2 Likes