exoscale-cli would like to read/write “$HOME/.exoscale” as this is the configuration directory used by our non-snap binairies.
The latest version has its plug connected with
snap connect exoscale-cli:read-write-config
We would like this to be autoconnected.
Thank you very much,
The exoscale-cli snap is the clear owner of the “$HOME/.exoscale”. From the docs (The personal-files interface): 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.
Why is read access (to, for example, import from a non-snap install) not sufficient? Since the snap is co-installable with non-snaps, importing into $HOME (which is set to the snap-specific
~/snap/exoscale-cli/<revision> directory) ensures that the snap can’t break the non-snap and vice versa.
Thanks for your review.
The intent for us is to suggest our users use the snap as the main packaging method for distros that support it out of the box (at least, *buntus). The current situation is that our users download a deb we built from github (we don’t maintain apt archives, nor do we plan to). Ideally the snap would replace this rather atypical install path on (at least) ubuntu systems.
Non-ubuntu systems (the most popular for our users being MacOS via Brew and Arch linux via the AUR) source their configuration from $HOME/.exoscale/*, and it would be a win for us to not have to maintain per-platform configuration paths (the extra code path is one thing but it also impacts documentation, support, etc… not to mention it making it a much easier “sell” to internal stakeholders). Therefore, it would be ideal for us to have the snap read and write the configuration from the same place as everything else.
Your comment about having side-by-side installation is a good one - however we think the risk here is minimal for the following reasons:
- The configuration format is very simple, and unlikely to change in the forseeable future: we basically only store API credentials to access the service, no API version-specific state (changing the format of our access keys in a backwards-incompatible way is not something we can realistically do regardless of packaging).
- We don’t expect people to install our deb manually and the snap in significant numbers.
- We are happy to absorb the support load for the few users that would install both, in the case we change the configuration format for some exotic reason.
Thanks again for your time and consideration.
Allowing read/write access to
+1 for read/write access to ~/.exoscale provided the snap is modified to use:
2 votes for, 0 against for read/write access with auto-connect for $HOME/.exoscale using the ‘dot-exoscale’ interface alias.
This is now live. Please update your snap accordingly. Please note that the review-tools currently require a corresponding update for this to pass automated review. This has been committed but not yet in production. In the meantime, you can request a manual review.