Abhilash Raj writes:
So, envlist doesn't really represent the list of supported versions. [...] envlist represent the exact list of env that will be used if you run
tox,
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.
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.
Also, the envlist for Postorius is just unuseful. Django-1.1.1? LOL
What I think we should do is
- Put a full list of Django versions that we have ever supported in the deps variable.
- Put the full list of Python-Django combinations that are supported (where Django is relevant).
- Standardize on lint for syntax checking and cov for coverage analysis.
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".
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. ;-)
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.
Regards,