Replace the generator and add add missing actions

[michael-k]

This PR includes a GitHub Action that automates the updates of IAM Actions. The GitHub Action runs every Monday and pushes updates to the default branch.

[michael-k]

pyflakes is failing on Python 2.7 and 3.5 because the scraper was written for Python 3.8+.

We could switch to flake8 which also runs pyflakes but allows to exclude directories. Or drop support for Python 2.7 and 3.5 which are both past their EOL (for 3.5 see https://www.python.org/dev/peps/pep-0478/#release-schedule).

[markpeek]

This is awesome. Thank you @michael-k!

Some questions:

• Since the generated code is still compatible with 2.7, likely we could leave that support in still. Could add into setup.py "!=3.5.*"?
• Is python now mapped to python3 in the latest ubunutu? Should the README and github actions be more explicit with python3 for a bit?
• The github action checks in changes automatically, is there a downside in doing this in case the scraper has an issue? Or do you feel it could be backed out, fixed, and still needs a release to publish anyway?
• I would like to have some of the tests running. I'm guessing your comment about pyflakes is more due to running it on python 2.7? Should we just assume all development and tests should use python 3.8?

[michael-k]

Since the generated code is still compatible with 2.7, likely we could leave that support in still. Could add into setup.py "!=3.5.*"?

• 2.7: yes it is
• 3.5: sure, but I'd like to leave it out of this PR if possible (but didn't; see last section)

Is python now mapped to python3 in the latest ubunutu? Should the README and github actions be more explicit with python3 for a bit?

• Ubuntu: I have no idea.
• I've updated the README to reflect that the scrape code requires Python 3.7+ (I haven't tested it with 3.7, but it should work; > 3.7 won't work due to https://docs.python.org/3/library/asyncio-task.html#asyncio.run
• The GitHub Action maps python to whatever actions/setup-python@v2 installs.

The github action checks in changes automatically, is there a downside in doing this in case the scraper has an issue? Or do you feel it could be backed out, fixed, and still needs a release to publish anyway?

If the scraper fails, it shouldn't create a commit, instead the GitHub Action is marked as failed. If it does something weird, it'll commit something weird. The trade-off is between reviewing one PR (the GitHub Action could create a PR instead of pushing to the default branch) each week and reviewing all changes at once on release. If you prefer PRs, I could help reviewing them.

I would like to have some of the tests running. I'm guessing your comment about pyflakes is more due to running it on python 2.7? Should we just assume all development and tests should use python 3.8?

The tests can all run under Python 2.7 and 3.5–3.9 as they don't import anything in ./scrape. Only pyflakes . fails because it covers ./scrape and the syntax is invalid for Python 2 (async/await) and 3.5 (variable annotations).

Possible workaround for pyflakes .:

• Don't invoke pyflakes directly, use flake8 instead and exclude ./scrape (we can still lint the code, but I'll probably add a separate job for that and use flake8, black, and isort)
• Remove ./scrape if Python < 3.6
• ~Drop support for Python < 3.6~

I've added commits that drop support for Python 3.5 and implement the second option (just because it was the simplest one). The tests are passing now: https://travis-ci.org/github/cloudtools/awacs/builds/732744788

[markpeek]

Released as awacs 1.0.0.