Make sure we don't try to include an empty set

[aleixpol]

This happens when snapcraft loads the configuration in cleanbuild to
retrieve the name and some other metadata. It's too early to resolve the
parts and they are null outside of the container.

---

• Have you followed the guidelines for contributing?
• Have you signed the CLA?
• If this is a bugfix. Have you checked that there is a bug report open for the issue you are trying to fix on bug reports?
• If this is a new feature. Have you discussed the design on the forum?
• Have you successfully run ./runtests.sh static?
• Have you successfully run ./runtests.sh unit? < some tests fail but they also failed before as well

[kyrofa]

Missing some tests here, which we can of course help with. Other reviewers: another option for this is to stop parsing the config so completely before spinning up a cleanbuild (this applies to persistent containers as well). I'm slightly concerned that, while this patch works, it'll be easy to introduce similar behavior in the config parser that breaks on other distros in the future. Thoughts?

[kalikiana]

Good catch! I actually tried out snapcraft cleanbuild on Fedora the other day, so good timing! I can reproduce it with a snap that uses a git part.

It occurs to me this sort of works because of DummyRepo.get_packages_for_source_type - all other methods will fail with NotImplementedError(). I feel that method should never be called in the first place...
How about lazily loading the PartsConfig in _config.py? eg. make parts a property and assign it the first time it's called.
If we wanted to go one step further, maybe a slimmer base class for Config that only processes metadata would actually be more future proof? Ideally it would not contain anything that goes beyond reading the YAML.