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.