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 ` 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
>
> 1. 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?
> 2. Put the full list of Python-Django combinations that are supported
> (where Django is relevant).
Put that where? In envlist?
> 3. 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 `tox` to run the test suite once and use
> > the explicit `-e` flag 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:
https://gitlab.com/mailman
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)
___
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@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
