@lucyllewy, is this possible with current snapd? Or would this need changes on snapd?
Also, if snapd pulls in the CUPS Snap automatically, it can come to problems:
Currently, if you install the CUPS Snap and there is already a classic installation of CUPS, the CUPS Snap’s cupsd will run in parallel on port 10631, so the CUPS used by default stays the classic one.
In the future, there will be also a migration possibility, which would mean that the CUPS Snap gets installed and the classic CUPS removed, overtaking all configuration (queues, …) into the CUPS Snap. This requires all classic drivers retro-fitted into Printer Application Snaps, as classic drivers are not supported by the CUPS Snap. Also this migration will most probably not be triggered by the CUPS Snap itself as it is not able to uninstall a classically installed package, but rather by some distro package manager performing a general update, for example to a new distro release, and doing the migration as part of it. I will add the script to overtake the configuration to the Snap, but only later, if I have more Printer Applications for testing.
Also at least for Ubuntu the installation of a user application Snap which prints does not necessarily need to migrate CUPS to the Snap automatically, as the Ubuntu package of CUPS has the same security feature for administrative inquiries to the CUPS daemon as the Snap. It checks the same way whether the inquiry is from a fully confined Snap and if so, only allows it if the Snap plugs “cups-control”.
So for now let us apply the three auto-connections I have asked for in the beginning of this thread as we have the needed 3 votes for them.