On 10/28/23 01:59, Odhiambo Washington wrote:

Running an install on Debian12 VM. Getting a new error message that I haven't seen previously:

(venv) mailman@debian12:~$ mailman-web compress Compressing... Invalid template socialaccount/login_cancelled.html: Invalid block tag on line 7: 'element', expected 'endblock'. Did you forget to register or load this tag? Invalid template account/verified_email_required.html: Invalid block tag on line 7: 'element', expected 'endblock'. Did you forget to register or load this tag?

These templates are part of django_allauth. What is your version of that? There are backwards incompatible changes in version 0.58. See https://github.com/pennersr/django-allauth/blob/main/ChangeLog.rst#backwards...

If you have 0.58 try

pip install django_allauth\<0.58

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Sat, Oct 28, 2023 at 7:19 PM Mark Sapiro <mark@msapiro.net> wrote:

On 10/28/23 01:59, Odhiambo Washington wrote:

...

Running an install on Debian12 VM. Getting a new error message that I haven't seen previously:

(venv) mailman@debian12:~$ mailman-web compress Compressing... Invalid template socialaccount/login_cancelled.html: Invalid block tag on line 7: 'element', expected 'endblock'. Did you forget to register or load this tag? Invalid template account/verified_email_required.html: Invalid block tag on line 7: 'element', expected 'endblock'. Did you forget to register or load this tag?

These templates are part of django_allauth. What is your version of that? There are backwards incompatible changes in version 0.58. See

https://github.com/pennersr/django-allauth/blob/main/ChangeLog.rst#backwards...

(venv) mailman@debian12:~$ pip freeze | grep django-all django-allauth==0.58.0

If you have 0.58 try

pip install django_allauth\<0.58

>

After that, I end up with:
(venv) mailman@debian12:~$ pip freeze | grep django-all
django-allauth==0.57.0

And then `mailman-web compress` is happy.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]

Consequent upon this django-allauth issue and the previous issue with psycopg2, how likely is it that new MM3 installations will suffer the effects? I am asking because I am doing my tests on a relatively vanilla system and just following the official documentation sin any deviations.

The allauth issue will happen until the allauth package is patched. Mark's patch was merged yesterday, so I suspect a new release will be imminent.

I've noticed the django-allauth ecosystem seems to be somewhat prone to breaking changes. I'm sure this discussion has happened before, but it may be worth pinning "known good" dependency versions for django-mailman -- either in the project, or in your documentation. It's definitely a headache for me since I rebuild my mailman container roughly weekly, and always need to allow time for functional testing or rollback to my last image.

There's not really a right answer here; either dependency versions are left open and the end user gets security updates for dependencies on their own schedule, or the Mailman maintainers have to monitor for security updates in the dependency tree and push a new mailman release. (This can also help ameliorate supply-chain attacks where an unverified update ends up in PyPI, but I'm not sure that's a realistic threat model for us.) I'm sure this is something the maintainers have considered in the past.

--Jered

Jered Floyd writes:

I've noticed the django-allauth ecosystem seems to be somewhat prone to breaking changes. I'm sure this discussion has happened before, but it may be worth pinning "known good" dependency versions for django-mailman

That's a double-edged sword, of course, because you will not get security upgrades etc either.

It seems to me that we generally only pin when there's a strong sense that the incompatibility will continue into the future. My sense is that it's not that allauth is subject to breaking changes (ie, deliberate backward incompatibility), more that it's prone to bugs that affect Mailman. In this case we see that django-allauth responded promptly with what appears to be a release to address this problem. I think that validates our past practice.

I think it's a good idea to keep a known-good requirements.txt from pip freeze around, but I'm not sure we should provide it.

On 10/30/23 20:58, Stephen J. Turnbull wrote:

Jered Floyd writes:

...

I've noticed the django-allauth ecosystem seems to be somewhat prone to breaking changes. I'm sure this discussion has happened before, but it may be worth pinning "known good" dependency versions for django-mailman

That's a double-edged sword, of course, because you will not get security upgrades etc either.

I agree, but past few days I've been thinking if we should do _something_ about it so that after a while 'pip install' doesn't just start failing for folks forcing us to do another release to pin to a version that we support.

In the past, we've had to do that a couple of times for various packages and maybe it doesn't make sense for to pin to a very specific version, but maybe we can provide a requirements.txt with "~=" compatible release requirements so it doesn't stop newer bugfix/security releases from being installed.

There will still be issues with packages that don't follow semver or unknown bugs (which was the case IIUC in allauth) that creep up, but it can still prevent us from intentional compat changes made by bumping major version.

Thoughts?

-- thanks, Abhilash Raj (maxking)

even after updating djengo-allauth to 0.60.1 the problem stay here is the snip $pip freeze | grep django-all django-allauth==0.60.1 $mailman_web compress >> Compressing... Error parsing template socialaccount/signup.html: socialaccount/base.html after downgrade to 0.57.0 $pip install django-allauth==0.57.0 $mailman_web compress >> Compressing... done Compressed 2 block(s) from 124 template(s) for 1 context(s). no errors this is very frustrating not able to buil working VENV mailman. my be the howto document must give the perfect working packages with exact version. for me each time i build venv i have different warning or erro.

On 1/24/24 02:38, amg hsn wrote: working packages with exact version.

for me each time i build venv i have different warning or erro.

I understand your frustration and I'm sorry.

The problem is that the current release of django-mailman3, 1.3.11, just requires django-allauth>=0.56, so a new install will get the latest django-allauth==0.60.1, but django-mailman3==1.3.11 is not compatible with django_allauth>=0.59. This will be fixed in the next release, but in the mean time, you can apply https://gitlab.com/mailman/django-mailman3/-/merge_requests/237/diffs and https://gitlab.com/mailman/django-mailman3/-/merge_requests/243/diffs to update django-mailman3 for compatibility with the latest django-allauth.

This can be an issue when any of our third party dependencies is upgraded in an incompatible way. Short of pinning all the dependencies to a specific version, there's not much we can do about it.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan