Hello! I would like to request auto-connections for ludo snap. Ludo is a libretro frontend in development (for playing retro games). https://github.com/libretro/ludo
Can you please explain why the existing snap-specific $HOME is not suitable for ludo? If this were to be granted and a user were to then install a non-snap version of ludo, would the shared use of the readl $HOME/.ludo between the snap version and the non-snap version cause issues?
+1 from me for joystick and removable-media auto-connect (esp given the RPi use-case for removable-media).
App is coded to save settings and data in $HOME/.ludo. Current snap works but is not able to save anything so it’s more a need then a desire to have that write permission. I can’t release a snap without write permission or code changes to path lookup.
It could be a problem in the future when more packaged releases become available (only tar releases on Github), but for now it sounds like a feature, user running tar release and then switching to snap version and continuing with same settings.
@predr - sure but in the context of the snap, the HOME environment variable is redefined to $HOME/snap/<snap-name>/<revision>/ - so if the app uses the path $HOME/.ludo then this should just work - how is the application looking up this path since it must not be using $HOME? Can it be made to use $HOME instead?
As far as using the same settings, you could request just read permission for the real $HOME/.ludo and then copy the settings across - then there is no chance that the tar release and the snap release could conflict - this is the primary use-case of the personal-files interface.
@alexmurray It’s coded to use original /home so it must be hardcoded somewhere probably with /home/$USER/.ludo and is not able to read or write because of confinement.
open /home/predr/.ludo/settings.toml: permission denied
Loading failed: open /home/predr/.ludo/settings.toml: permission denied
[Settings]: Using default settings
I was hoping to get write permissions now, and then later downgrade to read permissions after path has been fixed and import setting implemented.
I can see this comes from the use of the go os.user module - https://github.com/libretro/ludo/blob/master/settings/settings.go#L83 - other snaps have accomodated this in the past by making a small patch to first check $HOME and then use the real-home if that fails - Go HomeDir reads /etc/passwd, not $HOME - would that be a possibility?
@alexmurray Hey, thanks for looking into it! Yes, that looks like the issue, but it’s going to take a while to fix, test, release and snap.
If I’m assuming correctly that you are not willing to give me write perms, then I’ll take read perms (if that offer is still on table) and postpone snap release until path is fixed and import settings implemented.
Updated original post to change request for “config-ludo” to read-only and added link to Store page.
I have already added personal-interface to snapcraft.yaml and triggered manual review, do I need to request that in another post or will it be cleared when read-only perms is granted?
Can I get more votes on this and get manual review cleared?
+1 from me for read of config-ludo as defined in the snap.yaml of the most recent store revision:
config-ludo:
interface: personal-files
read:
- $HOME/.ludo
+1 for use of and auto-connect of personal-files with read access to $HOME/.ludo using the config-ludo interface reference.
+1 for joystick
A reluctant +1 for auto-connect of removeable-media based solely on the raspberry pi use case.
Granting all of this. These are now live.
@alexmurray - it just occurred to me that it would be more conventional to use dot-ludo for $HOME/.ludo, but it is granted and config-ludo conveys enough to the user to not force changing things now.
@jdstrand Configuration will likely be moved to .config/ludo in future and I didn’t want to change name later so I requested config-ludo. When that happens I’ll request additional read access to that directory. Now I just need manual review cleared for latest revisions.
I approved revisions 12 and 13.