'universal-ctags' requests personal-files interface

tartley · November 7, 2019, 3:27pm

Snap ‘universal-ctags’ requests use of personal-files interface to allow read access to files in ~/.ctags.d/

Universal-ctags reads config files from this directory

It is my intention that users installing this snap can continue to use the same config files that they have previously been using with apt or source installs.

I’ve added the ‘personal-files’ interface to my yaml under the name ‘dot-ctags’:

github.com

universal-ctags/ctags-snap/blob/master/snap/snapcraft.yaml#L53


   * User's `~/.ctags.d/` is read as expected. (But see the note
     in 'Usage' about giving the snap permission.)
   * Current directory's `ctags.d` is not read by default,
     but the '--options' arg can be used to read from it.
   * Current directory's `.ctags.d` cannot be read.
3. Configuration in other places, specified using `--options`
   or `--options-maybe`, will not be read if they are outside the
   user's HOME, or in a top-level hidden directory.
4. Tag files written using '-f' options or similar may not be outside
   the user's $HOME directory, nor in a hidden file or directory at
   top level in the $HOME directory. (You can work around this by
   using `-f -` and redirecting stdout to the required location.)
5. The universal-ctags 'man' pages are not installed.
6. The 'etags' executable alias (which defaults to Emacs style tags files)
   is not installed.

Due to which it is currently failing automated review:

Update: I should maybe mention that my snapcraft.yaml above generates a wrapper script around my snapped application, to reset $HOME to the user’s actual home directory.

Universal-ctags is a fork of the venerable exuberant-ctags (which puts config in a different place, just ~/.ctags)

Reynolds5 · November 7, 2019, 1:02pm

I’m afraid this isn’t a valid use case. Snap are supposed to keep dotfiles inside snap folder which is their $HOME.

tartley · November 7, 2019, 1:40pm

Thanks for the info @Reynolds5.

I was trying to follow the advice of @chipaca:

used in their ‘icdiff’ snap:

github.com

chipaca/icdiff/blob/master/snap/snapcraft.yaml#L18


  differences between similar files without getting in the way. This
  is especially helpful for identifying and understanding small
  changes within existing lines.
  Instead of trying to be a diff replacement for all circumstances,
  the goal of icdiff is to be a tool you can reach for to get a better
  picture of what changed when it's not immediately obvious from diff.
adopt-info: icdiff   # look for snapcraftctl set-* in the icdiff part
# personal-files won't auto-connect without going through the "Process for
# aliases, auto-connetions and tracks", https://docs.snapcraft.io/455
# like so: https://forum.snapcraft.io/t/9703
# During testing, "snap connect icdiff:gitconfig" should work
plugs:
  gitconfig:
    interface: personal-files
    read:
      - $HOME/.gitconfig         # the old location
      - $HOME/.config/git/config # the new location (people could change it via XDG_CONFIG_HOME and that isn't supported by snapd yet)

Can you help me understand why it’s ok in that context, and not in mine? Is dropping down to a classic snap a more appropriate way for me to achieve what I want?

roadmr · November 7, 2019, 2:05pm

+1 from me as reviewer, the requested directory is clearly related to ctags configuration, the request for read-only access is very sensible, and ctags config files don’t usually contain anything terribly sensitive.

Daniel

Reynolds5 · November 7, 2019, 3:10pm

There are two cases: your app own the target dir or it uses target dir owned by some third party app (as icdiff does for .gitconfig which is owned by git). In the former case your app should stay with snap $HOME. In the latter it may be allowed to access those third party dir manually or automatically. I thought your app owns that dir (first case). If not then please ignore my advice.

tartley · November 7, 2019, 3:24pm

@Reynolds5 Thanks for explaining your rationale, although obviously I don’t like that answer Yes you are right that this config dir is owned by the third-party app that I am packaging.

chipaca · November 7, 2019, 5:14pm

@tartley, do note @reynolds5 is not actually a reviewer; their opinions are their own.

Reynolds5 · November 7, 2019, 9:43pm

Then it would be nice if some reviewer either confirm or deny it. I’m basing my opinion on official docs which mention only import case from old dotfiles to snap $HOME plus historical reviews on this forum. The fact is even such households snaps like firefox or chromium aren’t allowed to store their configs in top level dotfiles (beside initial import) however I can’t rule out that it only depends on who is doing review.

chipaca · November 7, 2019, 9:43pm

that has already happened

Reynolds5 · November 7, 2019, 10:04pm

Where? The only thing you posted after my comment was that’s my opinion without sharing yours.

You can also see @jdstrand rejection of $HOME/.gitl_history in linked topic with similar argumentation to mine that it’s owned and used by specific tool and not supposed for share.

And here: Interface auto-connect request for the guvcview snap (personal-files)

In my first reply in this topic I misunderstood use case requested here which may be valid for personal-files in the end.

chipaca · November 7, 2019, 11:14pm

Reynolds5 · November 8, 2019, 6:06pm

Sorry but my question was about general rules and not about ctags at all and nothing in above reply touches anything I mentioned. It would be helpful not only for me but for all people requesting personal-files access to make things clear. Making enigmatic comments doesn’t really help anyone.

jdstrand · November 11, 2019, 11:46pm

As a reviewer, +1 for use of and auto-connection of personal-files for readonly access using the dot-ctags interface alias.

2 votes for, 0 against. This is now live. Note that a corresponding change is needed in the review-tools, and while this change is now in master, it is not yet in production. Until this is in production, we’ll manually approve new revisions of this snap.

@Reynolds5 - thank you for participating in the process. While each snap is different, the general guidelines for use of personal-files is documented here: The personal-files interface. Specifically, this snap is using personal-files for the typical use case: “This interface is typically used to provide read-only access to top-level hidden data directories within a user’s home directory in order to support importing data from existing applications where the snap is the clear owner of the target directory.”

Reynolds5 · November 12, 2019, 12:24pm

@jdstrand I linked same thing before so linking it back is rather pointless. Nevertheless the description provided there is vague and not enough to make things clear for everyone. For example use-case from this topic doesn’t match interface description. Adding more typical use-cases (also negative use-caseses) would help.

I think clear rules are important in order to not create double standards and make sure all snaps are treated equally.