Sadly, I do not think this is a good change.

When we bump a Python version like this, it means that anyone using this action, will get a flake that runs on Python 3.9. This is not a problem if your project is 3.9, but it might be when it is 3.8.

Mainly, and this is true for a few of my projects, flake8 is the only linter I have running. This basically means it is my only guard that if I say it is Python 3.8, it really is Python 3.8, and that I am not sneaky using something from Python 3.9. My local Python is 3.9, so during local testing I won't spot this.
Currently my most common mistake there is the new typing things from 3.9 (the List vs list). This happens when your newer projects are 3.9+ :)

So, bumping this action to 3.9 for everyone just isn't going to work for me. But this does show a much bigger problem this action currently has.

Back when I created it, it appeared that Docker would be the best way to create GitHub Actions. We assumed GitHub would add caching for them, so they are really quick, but as time as gone by, it becomes clear this not being the case. In fact, Docker-based actions are one of the more slower ways to do an actions atm.

There are some additional problems with this action, like you cannot install any additional flake plugins, if you so like. And if you want to stay on Python 3.7, it is not a nice fit either.

So, I have been wondering the last few weeks if I shouldn't change this action into a composite action. Sadly, composite actions work really quirky, but it might help us out here. It would make this action also a bit more the same as others.

Basically, it would mean something like this:

    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-python@v2
      with:
        python-version: 3.9
    - uses: TrueBrain/actions-flake8@v2

The "Set up Python 3.9" step can be skipped, and it would default back to the OS-wide Python (3.8 for ubuntu-latest).
As I mentioned, composite actions are really quirky, and for example you cannot do the "Set up Python" step via this action. That would make it nice and tidy. But owh well.

The other route would be to make this action a "insert-matcher-only", as that is basically the added value of this action vs just doing flake yourself. It will look something like this:

    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-python@v1
      with:
        python-version: 3.9
    - uses: TrueBrain/actions-flake8-matcher@v1
    - run: |
        python -m pip install --upgrade pip
        pip install flake8
        flake8

It completely frees up everyone to use it how-ever they please. But it would add a few more lines of workflows to make it happen. So personally, not a fan of this, but I do wish GitHub would solve this problem by allowing to include workflows from other projects. That would really help out a lot.

Anyway, I will see what I can do today to make the first change I mention, as that changes this action little and allows your request. As added bonus it would make this action run a whole lot quicker :D

Okay, "fun" fact: flake8 on Python 3.8 accepts list[int] as typing just fine. It is the relaxed way of decorators I ran into the other day :) Well, different problem, same story :P

@v2 is released. See https://github.com/TrueBrain/actions-flake8#different-python-version how to get it to work with Python 3.9 :)

When we bump a Python version like this, it means that anyone using this action, will get a flake that runs on Python 3.9. This is not a problem if your project is 3.9, but it might be when it is 3.8.

Yeah fair point, although conversely if you're targeting 3.7, or need to cover various versions.

Mainly, and this is true for a few of my projects, flake8 is the only linter I have running. This basically means it is my only guard that if I say it is Python 3.8, it really is Python 3.8, and that I am not sneaky using something from Python 3.9.

Just a warning on this front, having been finally doing some 2.7 to 3 compatibility flake8 didn't pick up e.g. iteritems, whereas https://github.com/marketplace/actions/python-code-quality-and-lint did some better static analysis and caught a lot more.

Back when I created it, it appeared that Docker would be the best way to create GitHub Actions. We assumed GitHub would add caching for them, so they are really quick, but as time as gone by, it becomes clear this not being the case. In fact, Docker-based actions are one of the more slower ways to do an actions atm.

I'd assume you could build and release a new Docker image each time you release a version, but I'm not really too hot on the specifics of that.

So, I have been wondering the last few weeks if I shouldn't change this action into a composite action. Sadly, composite actions work really quirky, but it might help us out here. It would make this action also a bit more the same as others.

Yeah makes sense.

The other route would be to make this action a "insert-matcher-only", as that is basically the added value of this action vs just doing flake yourself.

Yeah I guess it depends if you're just using the .flake8 config or doing other steps beforehand etc.

So in codespell we actually do both, there's a standalone problem matcher action:
https://github.com/codespell-project/codespell-problem-matcher

Which is then included via a submodule:
https://github.com/codespell-project/actions-codespell

It completely frees up everyone to use it how-ever they please. But it would add a few more lines of workflows to make it happen. So personally, not a fan of this, but I do wish GitHub would solve this problem by allowing to include workflows from other projects. That would really help out a lot.

Yeah agreed.

Anyway, I will see what I can do today to make the first change I mention, as that changes this action little and allows your request. As added bonus it would make this action run a whole lot quicker :D

Awesome thanks!

@v2 is released. See https://github.com/TrueBrain/actions-flake8#different-python-version how to get it to work with Python 3.9 :)

Amazing thanks, the composite stuff seems cool too.