On Wed, Jun 9, 2021, at 9:40 AM, Stephen J. Turnbull wrote:
I understand how tox defines envlist, but I would expect that it would basically tell you what you can expect to run tests with and pass.
I agree it should, i'll keep it in mind when updating tox configs next time.
but usually I just do
tox -e <envname>and this works even for Python versions not in the envlist.Me too; I've been short on space on my main workstation, so I'm usually down to one full suite of Python and my packages at a time.
But that works for Python versions because Python is very special. It *doesn't* work for Django, in particular.
True, we define the supported Django versions explicitly in tox.ini, one per minor version. Sometimes, it gets out of date.
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.
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?
- Put the full list of Python-Django combinations that are supported (where Django is relevant).
Put that where? In envlist?
- Standardize on lint for syntax checking and cov for coverage analysis.
Agreed!
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"
I have been considering putting just one latest Python version in envlist so I can just do
toxto run the test suite once and use the explicit-eflag for CI, which we already do.I think that a simple tox invocation should be reserved to the users. I mostly run tox on the whole suite from a script, in the background (ie, when I'm at lunch, a meeting, or a class). If I'm doing unit tests on an in-process branch, I generally run nose2 directly anyway. (Obviously other people do things their way, and I'm completely open to reason on the issue. ;-)
I have almost stopped running the full CI locally and just relying on CI to run other version jobs if one passes locally.
We should, yes. I am trying to to figure out if I can define the CI definition in a single repo and have that used in all the Mailman projects. Haven't had time to figure that out yet :( Github Actions provides a good way to share CI configs, maybe Gitlab has some way too!
I'm way behind on that tech. :-(
This is a very fun one actually, I have been trying to think of how to fix this. The version of Django-latest is > one supported (in setup.py) by P.
Does Postorius still support Django 1.1.1?!
Yes, but there aren't any docs
Speaking of missing docs, the top page on GitLab is woefully lacking in guidance on which of the subprojects you need for a functional system, which are documentation, which are example configuration, and which are experimental.
When you say "top page on Gitlab", do you mean something like:
or the one for Core:
https://gitlab.com/mailman/mailman
The former doesn't have any customizations we can do, no "group" level README available. But we can add this to Core's landing page within the README.rst.
Or did you mean something else by top page?
thanks, Abhilash Raj (maxking)