ifacetool provides tooling to work with snap interfaces, in particular their policies as realized via snap-declarations. One central feature of ifacetool is simulating what snapd will do in terms of auto-connections for a group of snaps given snap metadata and snap-declaration content. Installation ============= snap install --beta ifacetool To operate ifacetool needs to retrieve information from the store, it can do so using `snapcraft login` credentials. These can be made available by: * snap connect ifacetool:password-manager-service OR * setting SNAPCRAFT_STORE_CREDENTIALS as per https://forum.snapcraft.io/t/snapcraft-authentication-options Commands ========= fetch ------ ifacetool fetch [--no-decls] [--no-meta] <snap-name>[@rev]... fetch fetches snap metadata (at the given optional revisions) and snap declaration content for a set of snaps. For each snap it creates directories in the current working dir that look like this: <snap-name>/ .snap.json revision snap.yaml plugs.json slots.json snap.yaml is the snap metadata, while plugs/slots.json are the content of the snap declaration interface rule stanzas. These directories named after the snaps are the input for all other commands, they also allow to apply tentative modifications to the metadata or the snap-declaration rules to test. For convenience <snap-name> can also be a path pointing to a .snap file or directly to a local snap.yaml file. The file extension is used to detect this usage. Snap metadata will then come from those local sources. The snap overall still needs to exist in the store for its snap-id etc. auto-connections ----------------- ifacetool auto-connections [--classic] [--store <store-id>] [--model <brand>/<model>] [-i|--interface <interface>] [--candidates] <target-snap> [<context snap>...] auto-connections using the input from the corresponding snap directories (see fetch) does two things: * checks whether all snaps mentioned on the command line can be installed according to the rules * simulates which auto-connections would be established when installing target-snap, assuming the presence of the listed context snaps, and prints the auto-connecting slot/plug pairs The output report has two corresponding parts: * installation report * auto-connections reported with lines of the form: other-snap:plug < target-snap-slot other-snap:slot > target-snap-plug : target-snap-plug for any plug that is still left unconnected this part can be filtered to only show connections and plugs for a given interface using -i|--interface <interface> --candidates enables listing of candidates that were considered in the case were there was auto-connections but multiple candidates were in play or in the case that no auto-connection was established. For each candidate the result of checking whether it is allowed is displayed: * `=> ok` allowed * `=> ok slots-per-plug:*` allowed with `slots-per-plug: *` * `=> <error>` not allowed with error * `=> //` same error as the previous candidate The notation `{<label>: <value>}` displays the label attribute usually considered to allow auto-connection of interfaces like content, etc... --store and --model values are used when processing on-store/on-model/on-brand constraints in the rules. --classic requests to simulate the behavior as on a classic system, the default is an Ubuntu Core system. Changelog ========== 0.6 --- * support --candidates for further debugging * based/for snapd 2.57.5+ 0.5.1 ------ * switch to craft-store 2.3.0 to enable final snapcraft v7 exported auth 0.5 ---- * support filtering by interface with -i|--interface * support --classic 0.4 ---- * refined auto-connections output * fetch now supports taking metadata from local .snap/.yaml files * clarify license Ideas ====== review-tools at tag for snap.yaml can-install snap can-connect snap-plug snap-slot allow-installation slot-or-plug allow-auto-connection plugs and/or slot allow-connection plug and/or slot explain snap-name explain/lint snap-name [attr matching code]