[Mailman-Developers] Re: tox(ic).ini ;-)
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
> >
> > 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?
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,
> > 2. Put the full list of Python-Django combinations that are supported
> > (where Django is relevant).
>
> Put that where? In envlist?
Yes.
> > 3. 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:
>
>https://gitlab.com/mailman
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
___
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
[Mailman-Developers] Re: tox(ic).ini ;-)
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
[Mailman-Developers] Re: tox(ic).ini ;-)
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 ` 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 1. Put a full list of Django versions that we have ever supported in the deps variable. 2. Put the full list of Python-Django combinations that are supported (where Django is relevant). 3. 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 `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. ;-) > 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, ___ 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
[Mailman-Developers] Re: tox(ic).ini ;-)
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 ` 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-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
>
--
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
