'universal-ctags' requests personal-files interface

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’:

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)

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

Thanks for the info @Reynolds5.

I was trying to follow the advice of @chipaca:

used in their ‘icdiff’ snap:

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?

+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

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.

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

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

1 Like

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.

that has already happened

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.

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.

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.

1 Like

@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.

1 Like