I'm fiddling with my Python installations and noticed this:
steve Mailman/pristine 1:19 % grep envlist */tox.ini django-mailman3/tox.ini:envlist = py{37,38,39}-django{21,22,30,31},lint hyperkitty/tox.ini:envlist = py{36,37,38,39}-django{22,30,31},docs,lint mailman-hyperkitty/tox.ini:envlist = {py35,py36,py37}{,-coverage},lint mailman-web/tox.ini:envlist = docs mailman/tox.ini:envlist = {py35,py36,py37}-{nocov,cov,diffcov}{,-mysql,-pg},qa mailmanclient/tox.ini:envlist = py{35,36,37,38},lint postorius/tox.ini:envlist = py{35,36,37}-django{111,20,latest},pep8
We should do something about coordinating on supported versions, no? Also, coordinating common factors (cov vs coverage, pep8 vs lint vs qa)? Also, the djangolatest environment for postorius looks broken (but I don't understand tox that well):
django-latest: https://github.com/django/django/archive/main.tar.gzAlso, shouldn't every subproject support docs?
Steve
On Tue, Jun 8, 2021, at 10:39 AM, Stephen J. Turnbull wrote:
I'm fiddling with my Python installations and noticed this:
steve Mailman/pristine 1:19 % grep envlist */tox.ini django-mailman3/tox.ini:envlist = py{37,38,39}-django{21,22,30,31},lint hyperkitty/tox.ini:envlist = py{36,37,38,39}-django{22,30,31},docs,lint mailman-hyperkitty/tox.ini:envlist = {py35,py36,py37}{,-coverage},lint mailman-web/tox.ini:envlist = docs mailman/tox.ini:envlist = {py35,py36,py37}-{nocov,cov,diffcov}{,-mysql,-pg},qa mailmanclient/tox.ini:envlist = py{35,36,37,38},lint postorius/tox.ini:envlist = py{35,36,37}-django{111,20,latest},pep8
So, envlist doesn't really represent the list of supported versions. For that, you want to look at the .gitlab-ci.yaml in each repo, which is the source of truth for what we run CI on. It is a manually co-ordinated thing though, so we have to open PRs to each repo to add/remove and the list of envs vary on each project.
envlist represent the exact list of env that will be used if you run tox, but usually I just do tox -e <envname> and this works even for Python versions not in the envlist. I have been considering putting just one latest Python version in envlist so I can just do tox to run the test suite once and use the explicit -e flag for CI, which we already do.
We should do something about coordinating on supported versions, no?
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!
Also, coordinating common factors (cov vs coverage, pep8 vs lint vs qa)?
envlist is out-of-date but I think it is still different in separate repos. Would be good to unify them and figure out an automated way to keep them in sync.
Also, the djangolatest environment for postorius looks broken (but I don't understand tox that well):
django-latest: https://github.com/django/django/archive/main.tar.gz
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. Previously, pip would happily install it if the Django was installed before the project, but it has gotten smart and started failing installs if it cannot satisfy dependency constraints. In this case, it can't actually satisfy the constraints until we update setup.py to support the _next_ version of Django.
I don't know how to fix this, other than patching setup.py in django-latest job to remove the version constraint.
Also, shouldn't every subproject support docs?
Yes, but there aren't any docs in django-mailman3 and mailman-hyperkitty. I have been putting the changelog in README for django-mailman3, didn't seem worth setting up a RTD project just for changelog. All others have docs jobs and publish to Read the docs.
Steve
Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-leave@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
-- thanks, Abhilash Raj (maxking)
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,
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)
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
participants (2)
-
Abhilash Raj -
Stephen J. Turnbull