update Python, Django, and DRF versions & packaging configuration

[terencehonles]

This change is a proposal, it drops the EoL Python versions, and limits the Django support to the last two major versions (~4 years since release) and the DRF versions that support those versions.

[JoelLefkowitz]

Thanks @terencehonles, it's crazy to me that python3.9 is already approaching it's end of life. I'm not familiar with the Python :: 3 :: Only classifier, does it mean just 'not python 2'?

Do you know how the PyPI search works, or where the documentation is? If we have Python :: 3.9 will it be included if someone searches for Python :: 3?

The python3.6 test run can't be removed from the CI test matrix because I don't have access to the repository settings to disable the branch protection rule that requires it.

Only Cristi the original author has access to those settings. He's given me write access to the repository and PyPI permissions to publish which is exactly what we need to maintain the package and keep publishing new versions 🚀 #662. It makes sense for him to retain some of the settings access since he spent a long time developing the package from scratch and it's a big deal to give full access to someone else. I don't mind leaving the python3.6 run in the test matrix since it's immediately skipped.

[terencehonles]

Thanks @terencehonles, it's crazy to me that python3.9 is already approaching it's end of life. I'm not familiar with the Python :: 3 :: Only classifier, does it mean just 'not python 2'?

Yeah, it's crazy to me too 🤯, and yes, it just means the package doesn't support Python 2. It's not really required, but it's just to be clear to any scripts that it does not support Python 2 and not just that we've omitted a Python 2 classifier.

Do you know how the PyPI search works, or where the documentation is? If we have Python :: 3.9 will it be included if someone searches for Python :: 3?

I would kinda hope that it would do some basic substitution like this, but I really don't know, and it makes sense to just include Python :: 3 just in case.

The python3.6 test run can't be removed from the CI test matrix because I don't have access to the repository settings to disable the branch protection rule that requires it.

Only Cristi the original author has access to those settings. He's given me write access to the repository and PyPI permissions to publish which is exactly what we need to maintain the package and keep publishing new versions 🚀 #662. It makes sense for him to retain some of the settings access since he spent a long time developing the package from scratch and it's a big deal to give full access to someone else. I don't mind leaving the python3.6 run in the test matrix since it's immediately skipped.

I'm not sure how easy it is to contact Cristi (I'm slightly surprised you managed to do it, since I also reached out to him a bunch way back when), but does it make sense to see if he's willing to give you more permissions? The admin permission would work, but I think you're saying that might be higher than he want(ed/s) to grant, but looking at the docs, a custom role would also suffice. I'm not sure if that's something that is available for public repos or if that's a paid feature.

[terencehonles]

Looks like custom roles, are only for organizations, so the admin role would need to be granted to manage branch protections or the newer rulesets. Instead of just faking this, can you ask Cristi about getting that permission?

It would be good to enforce that the newer Python tests pass, since only 3.{6..9} are required, and that means we need to keep all of those and just have them bail out, but the newer tests aren't actually required and can be merged failing.

[JoelLefkowitz]

Thanks @terencehonles, I think we can make the test environments list a little cleaner by iterating the django version since the drf are linked directed to them:

py3{9,10,11,12   }-django40-drf{313,314,315},
py3{9,10,11,12,13}-django41-drf{313,314,315},
py3{9,10,11,12,13}-django42-drf{    314,315},
py3{  10,11,12,13}-django50-drf{    314,315},
py3{  10,11,12,13}-django51-drf{        315},
py3{  10,11,12,13}-django52-drf{        315},

I looked at some of the big packages on pypi and a lot of them have the Python :: 3 and Python :: 3 :: Only flag so I agree we should add them. I would prefer if we listed the classifiers statically in the pyproject.toml file rather than generating them dynamically in the setup.py script.

As far as admin permissions go I don't think we need to ask Cristi for a custom role since we have what we need to keep publishing new versions. I appreciate that it's not pretty to bail out some test runs on every PR but I've seen from experience that when someone takes a break it's important to be extra respectful of their space.

[terencehonles]

Thanks @terencehonles, I think we can make the test environments list a little cleaner by iterating the django version since the drf are linked directed to them:

py3{9,10,11,12   }-django40-drf{313,314,315},
py3{9,10,11,12,13}-django41-drf{313,314,315},
py3{9,10,11,12,13}-django42-drf{    314,315},
py3{  10,11,12,13}-django50-drf{    314,315},
py3{  10,11,12,13}-django51-drf{        315},
py3{  10,11,12,13}-django52-drf{        315},

I grouped by Python version because I thought it was easier to see, and would easily allow removing Python 3.9 when it hit EoL, but the way you put it seems reasonable since you could still remove the 9s from the list, and newer Pythons won't appear earlier in the support matrix so I went with your suggestion (putting Django 5.1 & 5.2 together though)

I looked at some of the big packages on pypi and a lot of them have the Python :: 3 and Python :: 3 :: Only flag so I agree we should add them. I would prefer if we listed the classifiers statically in the pyproject.toml file rather than generating them dynamically in the setup.py script.

Does it work to put these things partially in pyproject.toml and partially in setup.py? I would assume we want to just see about moving everything there rather than doing this change as part of this PR. It looks like we were trying to make sure our docs stayed correct by pulling the versions out of the README.

As far as admin permissions go I don't think we need to ask Cristi for a custom role since we have what we need to keep publishing new versions. I appreciate that it's not pretty to bail out some test runs on every PR but I've seen from experience that when someone takes a break it's important to be extra respectful of their space.

I don't think we want to bail out on "some tests" because it's actually all tests. I came up with another solution which is a bit of a hack and lies that we are testing on older Python versions (if someone were to look at the tests on a PR), but it addresses your concern about not bugging Cristi so you can tell me what you think...

[JoelLefkowitz]

Thanks @terencehonles, it's a tricky one to know how much to move to the pyproject.toml but my intuition is that we should move as much as possible. I'd like to move away from dynamic behaviour when packaging since it creates an opportunity for something to fail. Having a setup.py that does complex things, such as ours, seems to create a barrier to entry for other developers by being non standard.

In #929 I updated the runners to ubuntu-latest because our CI was failing. Since python3.6 is not available for the actions/setup-python@v5 step on the newer runners I have moved it to another job in the same action that emits a successful status like you have in this PR.

[terencehonles]

Thanks @terencehonles, it's a tricky one to know how much to move to the pyproject.toml but my intuition is that we should move as much as possible. I'd like to move away from dynamic behaviour when packaging since it creates an opportunity for something to fail. Having a setup.py that does complex things, such as ours, seems to create a barrier to entry for other developers by being non standard.

In #929 I updated the runners to ubuntu-latest because our CI was failing. Since python3.6 is not available for the actions/setup-python@v5 step on the newer runners I have moved it to another job in the same action that emits a successful status like you have in this PR.

@JoelLefkowitz I would like to get this merged instead of having the goal posts continue to move. Changes like these can come in subsequent PRs, and you know what you're looking for so you can propose a PR which meets your expectations.

Having that said, I've moved the properties from setup.py to pyproject.toml as you requested. I also verified that I could move all the dependencies to the pyproject.toml and did so.

[JoelLefkowitz]

Thanks @terencehonles, you are right 😃. I'm resolving the conflicts with the master branch now then we can merge. Thank you for all the hard work!

[JoelLefkowitz]

Thanks again @terencehonles!