Shfmt approval to use "personal-files"

Hello there.

I had snapped up shfmt some time ago using strict confinement. It turns out (had an issue reported on my repo) that the app will look at the $HOME/.editorconfig file for custom formatting rules.

I am not the upstream developer, but I do maintain this snap.

Is this something I can qualify for? I know this is reserved for vetted publishers. I am not sure what that process looks like - but can provide whatever is needed.

Thoughts?

you can use the “home” plug to access the home of the user.

home does not allow access to any hidden files (i.e. files and directories that start with a dot) so a snap can not just read other applications configs and passwords :wink:

Right… but then the HOME of the app should be the /snap/shftmt/current/ and then the app can see there … no?

this is correct … but i read $HOME above as the actual /home/$USER dir (which the home plug grants access to) :slight_smile: … perhaps i’m wrong though …

I think the same. But if the snap starts with the “correct” HOME, then his problem is solved. Sanps doesnt do that? start with the HOME pointing to ${SNAP}?

Maybe he wants to use the file from and old installation, without snap. The solution can be tell the user the new location of config files at start.

As others have stated, $HOME in the snap is ~/snap/shfmt/current so shfmt already has access to $HOME/.editorconfig so the snap should really be adjusted to use this. It is possible that the snap is using getpwent or similar to determine the user’s home directory. If so, perhaps upstream would take a patch to evaluate $HOME instead, falling back to getpwent/etc if it isn’t set?

Also, the name .editorconfig is quite general. Is this a file that is created by shfmt? Is there documentation for shfmt discussing this file?

Ok - that makes sense - I’ll get the user to test there and then add a note to the store page about the CFG change needed with the snap.

I appreciate the feedback from all!

@jdstrand - .editorconfig is a standard name and format for overriding and distributing editor configuration.

From the site:

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.

1 Like

Thanks @bashfulrobot - considering that and depending on how things work out, it should be fine to use personal files with ‘read’ access to this file. Let us know how you want to proceed.

@jdstrand

OK - I think I have run into a bigger issue. I spoke to the upstream dev to clarify how the feature is intended to operate. The file is not actually meant to exist there (which actually makes sense to me). The .editorconfig is actually supposed to be in the root of your project.

Now here is where the issue comes in - we cannot control where a developer may keep their code. In home, a separate drive, on an external device, etc.

Now because this is deviating from the original topic here, I should likely start a new thread. Or I am wondering if I should be simply starting a new thread requesting classic confinement as I am not sure how to approach this otherwise.

I know classic is to be avoided, but I’m not sure how to combat. I am going to go read docs in case there was a new feature I am not aware of. But welcome feedback.

If it is in the root of the project, then the home and removable-media interfaces should be fine, no? Projects are going to live in non-hidden directories, or am I missing something?

@jdstrand I think those two would cover “most” use cases. But I can also imagine people using other mounted drives as well. Any thoughts on this aspect?

I’ll refactor based on this suggestion and go from there.

If I can also get the approval for the personal files, that would be great. I assume it will still be needed with home and removable drive access.

Approval for personal-files will still need to be voted on - from my perspective, +1 from me for read access to ~/.editorconfig - can you please name this dot-editorconfig rather than the current read-editorconfig so it is clearer to users what this provides?

1 Like

Other mounted drives would be covered by removable-media, which covers /media and /mnt, so I think this is ok, no?

+1 for use of personal-files with auto-connection for read-only access to ~/.editorconfig using the dot-editorconfig interface reference.

2 votes for, 0 against for use of personal-files in this manner. Granting. This is now live.

@bashfulrobot - for your snap to pass automated review, please adjust it to be:

plugs:
  dot-editorconfig:
    interface: personal-files
    read:
    - $HOME/.editorconfig
1 Like

Note, a corresponding change is needed to the review-tools that is not yet in production. Feel free to request manual reviews until it is and a reviewer will manually approve.

Thank you! I just submitted a build with these changes. I see that it is pending a manual review.

It looks like it is pending review, so my assumption is that it will be reviewed as it makes its way through the review process.

Thank you.