feat: drop Python 3.7 support

[tombh]

@karthiknadig I think it's been 3 months since Python 3.7's EOL?

[tombh]

Great, thanks for that. How's that now? I also add a new lint sub-task to check if poetry.lock is up to date.

Still need to disable Python 3.7 in the Github Action matrix.

[dimbleby]

looks good to me, though I think libraries should be cautious of "poetry up". By bumping lower bounds as high as they will go, it increases the chances of unsolvable environments. (Curiously, tight upper bounds causing the same thing seem to get a lot more attention: but an upper bound can only be incompatible with a corresponding lower bound!)

eg you have bumped websockets to ">=12": but if older versions continue to work fine for pygls then there is a case for preferring ">=11.0.3"

[tombh]

Thanks David, that's another really good point. What would you say is a good rule of thumb for updating dependencies? Say, for example: beyond setting a minimum version that supports required functionality, we aim to be one major version below the latest. Obviously that's not a strict rule, like for cattrs that doesn't follow semver, it's just a rule of thumb.

[dimbleby]

I don't know a good rule except to use your best judgement.

I reckon that approximately no-one runs tests to verify that their code works with their declared lower bounds. So it can be pretty easy to inadvertently start using features that were new in eg websockets 12 without realising that the claimed "webockets >= 11" has become a lie.

So you are navigating between the rock and the hard place: make some sort of best effort not to have unreasonably narrow requirements, but also don't leave those requirements so broad that they're probably false.

I doubt that it's worth more than some modest amount of care though: users will tell you about it when you get it wrong!

[tombh]

That's fair, so at least be aware of the tradeoffs and try to find a balance without sweating too much over it.

Thanks for all your advice on this, I really appreciate it.