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 -- [email protected]
> To unsubscribe send an email to [email protected]
> 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)
_______________________________________________
Mailman-Developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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
