jonaslu
commented
3 years ago Allright, I'll document this for my own sake here.
Snapcraft is not a good idea, since ain uses your system curl or http binary. Snapcraft and it's security model does not allow a snap-binary to access the host-system (except for bind-mounts which are flakey, the curl and httpie-binary can be located on many paths on different archs).
So, why not just package ain with curl and httpie as stage-snaps then? Because the version packaged with ain is frozen in time. So while your system-version of curl and or httpie updates the ones in the snap stays the same. So this results in having to update the snap only to update the shipped curl and httpie snaps.
And there's a possibility that a [BackendOption] flag might work on your system-install version, but not in the ain snapped version (because of the manual update needed). Not to mention of the stage-snap version is lagging in the snap-store.
It's just not worth it, and it's not how ain is supposed to work. It's supposed to be a front-end for your system binary and this is not how snaps are meant to operate.
If this really takes of and everyone is screaming for a snap, the --classic flag would be a way to go. But the process seems involved: https://snapcraft.io/docs/reviewing-classic-confinement-snaps
Go releaser supports snapcraft builds, so why not do that?