Drop support for python < 3.9

[2e0byo]

Mopidy now requires 3.9 in dev, the commit has not yet made it to release. Can we revisit dropping support for 3.{7, 8}?

I've aimed for compatibility, but I'm not 100% sure everything I've written recently (some not PRd yet) will run on 3.7: I had to mark out some tests for using pathlib.Path.with_stem for instance, so I that code isn't tested.

I see two paths forward: wait for 3.5.0 to land, or don't release until then. Personally I prefer the latter but I don't really mind either way.

[tehkillerbee]

I see two paths forward: wait for 3.5.0 to land, or don't release until then. Personally I prefer the latter but I don't really mind either way.

Sorry, can you clarify what you mean with the above?

In my opinion, it depends on how soon 3.5.0 is released. As soon as it is released, it does not make sense to support python 3.7/8 any longer.

[2e0byo]

I just meant we could avoid pushing to pypy until mopidy does but still merge stuff requiring 3.9. I have some prs on the way which might break 3.7, mostly because I can't remember the differences very well and I'm too lazy to get the whole test suite running against a version we're dropping soon anyhow.

I guess we can always call 3.7 best effort if mopidy takes forever and fix the bugs if they get reported. In any case installing from git with pip is actually painless, so if we do wait on releasing we're not stopping anyone.

[tehkillerbee]

I just meant we could avoid pushing to pypy until mopidy does but still merge stuff requiring 3.9.

I think this is the way forward. I would also prefer to wait with a PyPi release, until we have a solution for the tidalapi abandonment.

I'm too lazy to get the whole test suite running against a version we're dropping soon anyhow.

I agree, it does not make sense to continue maintaining the tests, if we know they will drop support. Lets leave them in their current state, until the next release of Mopidy removes support for 3.7/3.8.