Abhilash Raj writes:
True, we define the supported Django versions explicitly in tox.ini, one per minor version. Sometimes, it gets out of date.
I don't have a problem with "sometimes". But the current situation looks unprofessional.
Also, the envlist for Postorius is just unuseful. Django-1.1.1? LOL
1.1.1 is probably a typo for 1.11 I think.
Sure, but still, Django 1?!
What I think we should do is
- Put a full list of Django versions that we have ever supported in the deps variable.
By ever supported, you mean even the ones we don't support anymore?
Yes. We could put in a comment that they're not necessarily supported by us, but there are always going to be people (RHEL...) who for whatever reason want to be a couple versions behind what we support. This would also go forward with versions that are still experimental.
The logic behind "ever supported" is that it's an easy rule to update to (just take the union of the version specs in various files), and we only do it once. After that, we only add "djangoXX: Django >=x.y, <x.y", we never delete them. We never have to make a decision that Django 1.11 is not just unsupported, but we're going to erase it. Once a version falls out of envlist (or whatever the ground source of truth for "supported" is), you're 100% on your own, we're not even going to tell you "sorry, that's Python 2 only and we don't do Python 2". But if somebody wants to run tests against Django 1.11, don't make them dig up the version spec that we already know. Ditto if somebody is running against Python:main, we put that in there and people can use it (although I hope nobody puts that in envlist! :-)
- Put the full list of Python-Django combinations that are supported (where Django is relevant).
Put that where? In envlist?
Yes.
- Standardize on lint for syntax checking and cov for coverage analysis.
Agreed!
Good!
Then people with a single version of Python and a single version of Django (which I think is going to be typical of non-core-developers including a lot of people who send patches) can just run "tox".
So, you suggest we put a single environment in envlist, something like:
envlist = "py39-django31"
No, that's not the way envlist works. I'm saying we put
envlist = py{36,37,38,39}-Django{22,23,30,31}(which expands to 16 combinations!) and somebody who only has Python 3.8 and Django 2.3 installed will only get that combination tested. ... Hm, on second thought I'm not sure if tox works that way for anything but "pyXX" by default, but I'm pretty sure we can tell tox only to test installed versions of Django, and not download them if they're not already installed.
I have almost stopped running the full CI locally and just relying on CI to run other version jobs if one passes locally.
Well, you could always vendor your tox.ini. ;-) I don't really object to just putting one version into envlist, but if we get into a situation where some people are working on compatibility the most recent Python while others are using something a couple of releases back, it could get annoying.
When you say "top page on Gitlab", do you mean something like:
This one.
The former doesn't have any customizations we can do, no "group" level README available.
That kinda sucks. It is possible to create subgroups (I guess "archived" is a special-purpose subgroup available by default). Not sure it's worth the effort. Too many things to keep synced!
But we can add this to Core's landing page within the README.rst.
That might be best. Or maybe just rely on readthedocs.
Steve