This PR aims to address some unusual `charmcraft pack` failures we've seen in CI, for example [in the charmlibs monorepo](https://github.com/canonical/charmlibs/actions/runs/28564481582/job/84688902250) and [with the Ubuntu charm](https://github.com/canonical/charm-ubuntu/actions/runs/28907087457/job/85756388863). The relevant output is: ``` + charmcraft pack Launching managed ubuntu 24.04 instance... Creating new instance from remote Creating new base instance from remote Creating new instance from base instance Starting instance Initializing lifecycle Installing build-packages Installing build-snaps Environment validation failed for part 'charm': 'uv' not found and part 'charm' does not depend on a part named 'uv-deps' that would satisfy the dependency. Failed to run charmcraft in instance Full execution log: '...' ``` An AI-powered investigation points to the culprit being in `craft-parts`, where `install_snaps()` gates the `snap install` call behind a successful snapd `/v2/find` store query; when that query fails transiently, `get_store_snap_info()` exhausts 5 zero-delay retries and returns `None` instead of raising, so the build-snap is silently never installed and the failure only surfaces later as a missing command. This PR makes two changes: 1. Don't gate the `snap install` call on the store query, so if the store is unavailable the install will fail loudly rather than surfacing only cryptically at validation time. 2. Try to make querying the store less likely to fail by adding a sleep between the retries, which would otherwise be performed back-to-back. We don't gate the `snap install` because: - Original snap support ([`da71b734`, 2021](https://github.com/canonical/craft-parts/commit/da71b73409330c049357fe2bc99f5c65327c5713)) made the install decision independently of the store query, failing loudly with a type error. - [`8aeb3ea8` — "packages: address issues raised by pyright 1.1.151"](https://github.com/canonical/craft-parts/commit/8aeb3ea8e32edccf04b47bae95eac2bface135c4) wrapped the whole block (including `snap_pkg.install()`) in `if store_snap_info:` to silence a None-indexing warning (the previous loud failure). This changed the behaviour on store query failure to silently skip installation. A sleep seems like a reasonable approach, because: - craft-providers restarts snapd during instance setup and guards the following API calls with a retry loop that waits between attempts, commented with: [`base.py`: "snapd claims it's ready but actually isn't (SNAPDENG-36387). The workaround is to retry."](https://github.com/canonical/craft-providers/blob/3.3.0/craft_providers/base.py#L625-L632) - craft-parts own snapd query retry loop ([`get_store_snap_info`](https://github.com/canonical/craft-parts/blob/5363f3fda4fb004e038eedaf012938814beee041/craft_parts/packages/snaps.py#L119-L144)) fires all 5 attempts back-to-back with no delay. - A sleep between retries is used elsewhere in craft-parts for CI-transient failures, e.g. the umount retry in [`utils/os_utils.py`](https://github.com/canonical/craft-parts/blob/5363f3fda4fb004e038eedaf012938814beee041/craft_parts/utils/os_utils.py#L259-L286) ("unmount in Github CI fails randomly and needs a retry", `time.sleep(1)` between attempts). --- - [x] Have you followed the guidelines for contributing? - [x] Have you signed the [CLA](http://www.ubuntu.com/legal/contributors/)? - [x] Have you successfully run `make lint && make test`? - [x] Have you added an entry to the changelog (`docs/reference/changelog.rst`)?