Operator framework charms will try to use the libyaml based PyYAML, which is significantly faster than the pure Python one. In an apt system, like Ubuntu, this requires `libyaml-dev` to build from source. If the libyaml dev files are not available, then the pure Python version will be built instead. Charms can get the faster version by including `libyaml-dev` in the `build-packages` section of the metadata, or by allowing PyYAML as a binary package (the wheel has the faster version). However, this is fairly esoteric knowledge. Since the charm plug-in is specifically for operator framework charms, and ops has PyYAML as a dependency so be required for every ops charm, it seems reasonable to have `libyaml-dev` as a build dependency, which means that everyone (on an apt-based system) will get the faster YAML processing for 'free'. Detailed timing for setting relation data can be found using the [example charm in this repo](https://github.com/pengwyn/charm-relation-test). Setting 4MB of relation data with the pure Python version takes around 2s, and with the libyaml version around 0.02s. This can be significant for some charms. A complete test for this would be to do a basic charm build and verify that the .so file is included in the `venv/yaml` folder, but I wasn't sure whether that sort of test would be appropriate for charmcraft or not. Let me know if I should work on that, assuming that you're inclined to accept this change.