Depend on PyYAML for yaml on python3

[andir]

This removes the vendored version of PyYAML3 has been outdated for a
while. Over the last few years there have been a couple of high severity
CVEs against PyYAML that are unfixed in the vendored version.

By declaring a dependency on PyYAML we can make use of the upstream work
that goes into fixing those issues at the low cost of having it as the
only external dependency.

[andir]

This apparently drops support for Python3.4 which isn't any longer any supported Python3 version. Should we keep the vendored PyYAML for that version? Obviously that will then still suffer from the potential issues in the vendored PyYAML version.

[andir]

@bitprophet Can you comment on this? The CI is currently failing (for the given reasons) but this fix should still be considered in some way or another.

[bitprophet]

Thanks for bringing this up! That said, I'd much rather get in the habit of upgrading the vendored copy; vendoring was done for a bunch of reasons and no-external-deps is one of the 'selling points' of the library. If you have the time to put together a different PR that does so, I'd much rather merge that version.

And re CI, I'm in the middle of moving to CircleCI and then adding a lot more automation afterwards. One of those automations should ideally be checking the versions of vendored libraries & notifying us somehow when they're outdated. (I know GH et al have increasingly robust tools for this for regular dependencies; it's possible there's a way to hack that in, eg keeping a requirements.txt in the vendor folder that tracks what's vendored.)

[andir]

Thanks for bringing this up! That said, I'd much rather get in the habit of upgrading the vendored copy; vendoring was done for a bunch of reasons and no-external-deps is one of the 'selling points' of the library. If you have the time to put together a different PR that does so, I'd much rather merge that version.

And re CI, I'm in the middle of moving to CircleCI and then adding a lot more automation afterwards. One of those automations should ideally be checking the versions of vendored libraries & notifying us somehow when they're outdated. (I know GH et al have increasingly robust tools for this for regular dependencies; it's possible there's a way to hack that in, eg keeping a requirements.txt in the vendor folder that tracks what's vendored.)

Thanks for getting back to me!

From looking at recent PyYAML versions it looked like all of them required native extensions for them to work. I am not sure how good it will be to basically maintain a parallel build system from the original project. Have you considered hiding the YAML feature behind and "extra" flag? For example in my work we use invoke but don't make use of any of the YAML features (knowingly).