Hi gang,
On mailman import21, I hit the error
TypeError: 'pathlib._local.PosixPath' object does not support the context manager protocol
I found the earlier thread, where Mark wrote
This is https://gitlab.com/mailman/mailman/-/issues/1190 fixed for Mailman 3.3.11 by https://gitlab.com/mailman/mailman/-/merge_requests/1309
I have
(venv) mailman@darni:~$ mailman version GNU Mailman 3.3.9 (Tom Sawyer)
I tried
(venv) mailman@darni:~$ pip install -U mailman postorius django-mailman3 hyperkitty mailman-web
to no avail, the TypeError is not fixed and the version is the same.
ok, so I need to spell out a version. Trying
pip install -U mailman==3.3.11 postorius django-mailman3 hyperkitty mailman-web
3.3.11 appears not to be available
pip install -U mailman==3.3.10 postorius django-mailman3 hyperkitty mailman-web
yields the familiar problem with the nntplib.
ERROR: Could not find a version that satisfies the requirement nntplib; python_version >= "3.13" (from mailman) (from versions: none) ERROR: No matching distribution found for nntplib; python_version >= "3.13"
I had earlier gotten around this by installing its successor, standard-nntplib, and it is still there.
(venv) mailman@darni:~$ pip3.13 install standard-nntplib Requirement already satisfied: standard-nntplib in /usr/local/mailman/venv/lib/python3.13/site-packages (3.13.0)
That used to work for 3.3.9. But the 3.3.10 version may have no verbiage to say that the nntlib is replaced by standard-nntplib
Now I seem to have managed to hose my environment.
(venv) mailman@darni:~$ mailman version Traceback (most recent call last): File "/usr/local/mailman/venv/bin/mailman", line 3, in <module> from mailman.bin.mailman import main File "/usr/local/mailman/venv/lib/python3.13/site-packages/mailman/bin/mailman.py", line 25, in <module> from mailman.core.initialize import initialize File "/usr/local/mailman/venv/lib/python3.13/site-packages/mailman/core/initialize.py", line 29, in <module> import mailman.config.config File "/usr/local/mailman/venv/lib/python3.13/site-packages/mailman/config/__init__.py", line 20, in <module> from mailman.config.config import Configuration File "/usr/local/mailman/venv/lib/python3.13/site-packages/mailman/config/config.py", line 32, in <module> from mailman.utilities.modules import call_name, expand_path File "/usr/local/mailman/venv/lib/python3.13/site-packages/mailman/utilities/modules.py", line 23, in <module> from pkg_resources import resource_filename, resource_listdir ModuleNotFoundError: No module named 'pkg_resources'
What now?
-- Written by Thomas Krichel http://openlib.org/home/krichel on his 22213th day.
Thomas Krichel writes
What now?
Actually it looks I could do
pip install -U mailman==3.3.9 postorius django-mailman3 hyperkitty mailman-web
To get back to a working system
But that still leaves me without 3.3.11 which I apparently need for my import21.
-- Written by Thomas Krichel http://openlib.org/home/krichel on his 22213th day.
On 3/29/26 7:57 PM, Thomas Krichel wrote:
Thomas Krichel writes
What now?
Actually it looks I could do
pip install -U mailman==3.3.9 postorius django-mailman3 hyperkitty mailman-web
To get back to a working system
But that still leaves me without 3.3.11 which I apparently need for my import21.
If you do that and it results in a working system, you can then patch mailman/utilities/i18n.py as follows --- a/src/mailman/utilities/i18n.py +++ b/src/mailman/utilities/i18n.py @@ -114,8 +114,7 @@ def search(resources, template_file, mlist=None, language=None): languages.append(language) languages.reverse() # The non-language qualified $template_dir paths in search order. - templates_dir = str(resources.enter_context( - files('mailman').joinpath('templates'))) + templates_dir = str(files('mailman').joinpath('templates')) paths = [templates_dir, os.path.join(config.TEMPLATE_DIR, 'site')] if mlist is not None: # Don't forget these are in REVERSE search order! However there are other incompatibilities between the released Mailman versions and Python 3.13. At the moment, until updated packages are released, in a Python 3.13 environment it is best to install all of mailman, django-mailman3, postorius, hyperkitty and mailman-web from the heads of the gitlab branches. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes
If you do that and it results in a working system, you can then patch mailman/utilities/i18n.py as follows
Thank you. This works, and I can successfully import a first list configuration.
However there are other incompatibilities between the released Mailman versions and Python 3.13.
Hmm https://docs.mailman3.org/en/latest/install/virtualenv.html states "3.13 is recommended as it is the latest version of Python with which Mailman is tested."
At the moment, until updated packages are released, in a Python 3.13 environment it is best to install all of mailman, django-mailman3, postorius, hyperkitty and mailman-web from the heads of the gitlab branches.
I would love to see a command line for that. When I go to the gitlab page, https://gitlab.com/mailman/, I see a bunch of project that don't immediately correspond to pip package names.
I am sure this would help other folks using 3.13 as they have been recommended to do.
Thanks and cheers!
-- Written by Thomas Krichel http://openlib.org/home/krichel on his 22213th day.
On Sun, Mar 29, 2026 at 6:11 PM Thomas Krichel <krichel@openlib.org> wrote:
Mark Sapiro writes
If you do that and it results in a working system, you can then patch mailman/utilities/i18n.py as follows
Thank you. This works, and I can successfully import a first list configuration.
However there are other incompatibilities between the released Mailman versions and Python 3.13.
Hmm https://docs.mailman3.org/en/latest/install/virtualenv.html states "3.13 is recommended as it is the latest version of Python with which Mailman is tested."
At the moment, until updated packages are released, in a Python 3.13 environment it is best to install all of mailman, django-mailman3, postorius, hyperkitty and mailman-web from the heads of the gitlab branches.
I would love to see a command line for that. When I go to the gitlab page, https://gitlab.com/mailman/, I see a bunch of project that don't immediately correspond to pip package names.
pip install git+https://gitlab.com/mailman/mailman@master pip install git+https://gitlab.com/mailman/mailmanclient@master pip install git+https://gitlab.com/mailman/mailman-hyperkitty@master pip install git+https://gitlab.com/mailman/hyperkitty@master pip install git+https://gitlab.com/mailman/django-mailman3@master pip install git+https://gitlab.com/mailman/postorius@master pip install git+https://gitlab.com/mailman/mailman-web@master
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Washington Odhiambo via Mailman-users writes
pip install git+https://gitlab.com/mailman/mailman@master pip install git+https://gitlab.com/mailman/mailmanclient@master pip install git+https://gitlab.com/mailman/mailman-hyperkitty@master pip install git+https://gitlab.com/mailman/hyperkitty@master pip install git+https://gitlab.com/mailman/django-mailman3@master pip install git+https://gitlab.com/mailman/postorius@master pip install git+https://gitlab.com/mailman/mailman-web@master
these commands, run in sequence, rather than a
pip install git+https://gitlab.com/mailman/mailman@master git+https://gitlab.com/mailman/mailmanclient@master git+https://gitlab.com/mailman/mailman-hyperkitty@master git+https://gitlab.com/mailman/hyperkitty@master git+https://gitlab.com/mailman/django-mailman3@master git+https://gitlab.com/mailman/postorius@master git+https://gitlab.com/mailman/mailman-web@master
as may be implied by the documentation, work without a hitch!
Thanks and cheers!
-- Written by Thomas Krichel http://openlib.org/home/krichel on his 22214th day.
Would it be preferred to have a section for "Install from Git Master" or a "Install development branch" section under Installation that addresses this? If so I can work to edit the site docs to make such sections.
Thomas
On 2026-03-30 07:39, Thomas Krichel wrote:
pip install git+https://gitlab.com/mailman/mailman@master git+https://gitlab.com/mailman/mailmanclient@master git+https://gitlab.com/mailman/mailman-hyperkitty@master git+https://gitlab.com/mailman/hyperkitty@master git+https://gitlab.com/mailman/django-mailman3@master git+https://gitlab.com/mailman/postorius@master git+https://gitlab.com/mailman/mailman-web@master
Thomas Ward via Mailman-users writes:
Would it be preferred to have a section for "Install from Git Master" or a "Install development branch" section under Installation that addresses this?� If so I can work to edit the site docs to make such sections.
I appreciate the thought, but I don't think it's useful in the general audience documentation. Installing from HEAD is always risky, especially for people using LTS distributions. The Django situation is always fraught.
Putting that recipe as is in the developer docs also doesn't make that
much sense to me, as developers are expected to have full clones of
the components they're working on. On the other hand something that
points at the dev's local repos of the Mailman Suite components does
make a lot of sense to me. Then you can add a note that "if you're
only interested in some of the components, you can automatically get
HEAD installations by substituting "https://gitlab.com/mailman/" for
your "/path/to/local/repos/" in the pip commands for the rest. That
makes sense to me because it means you don't have to keep a local
mailmanclient clone up-to-date just to work on Postorius. And
exercise for the reader: you can get your buddy's django-mailman3
hacks the same way.
What do y'all think?
Oh, yeah, probably ought to check the requirements.txt DAG to order the pip commands so that you're not overwriting PyPI versions with git master HEAD versions all the time.
Steve
On 2026-03-30 07:39, Thomas Krichel wrote:
pip install git+https://gitlab.com/mailman/mailman@master git+https://gitlab.com/mailman/mailmanclient@master git+https://gitlab.com/mailman/mailman-hyperkitty@master git+https://gitlab.com/mailman/hyperkitty@master git+https://gitlab.com/mailman/django-mailman3@master git+https://gitlab.com/mailman/postorius@master git+https://gitlab.com/mailman/mailman-web@master
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Stephen J. Turnbull writes:
Putting that recipe as is in the developer docs also doesn't make that much sense to me, as developers are expected to have full clones of the components they're working on. On the other hand something that points at the dev's local repos of the Mailman Suite components does make a lot of sense to me.
That would be somewhere in the neighborhood of mailman/src/mailman/docs/install.rst.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
With recent revisions I made to the general Installation page that leads to other pages [1], we could write a "Install-From-HEAD-DANGEROUS" document (akin to the existing virtualenv install documents but then specify alternative install commands to install from HEAD), detailing how to install from HEAD with the major disclaimer notice about this NOT being recommended unless you want or need to track Git HEAD.
The parent page there at [1] can thus have a huge disclaimer saying "You should only do this if you really need to or are intending to work with development of Mailman 3 and its components."
Happy to write a proposal of such a document for review.
Thomas
On 2026-03-30 13:45, Stephen J. Turnbull wrote:
Stephen J. Turnbull writes:
Putting that recipe as is in the developer docs also doesn't make that much sense to me, as developers are expected to have full clones of the components they're working on. On the other hand something that points at the dev's local repos of the Mailman Suite components does make a lot of sense to me.
That would be somewhere in the neighborhood of mailman/src/mailman/docs/install.rst.
Steve
Okay, so links get purged apparently [1] was supposed to point at https://docs.mailman3.org/en/latest/install/install.html
On 2026-03-30 13:49, Thomas Ward via Mailman-users wrote:
With recent revisions I made to the general Installation page that leads to other pages [1], we could write a "Install-From-HEAD-DANGEROUS" document (akin to the existing virtualenv install documents but then specify alternative install commands to install from HEAD), detailing how to install from HEAD with the major disclaimer notice about this NOT being recommended unless you want or need to track Git HEAD.
The parent page there at [1] can thus have a huge disclaimer saying "You should only do this if you really need to or are intending to work with development of Mailman 3 and its components."
Happy to write a proposal of such a document for review.
Thomas
On 2026-03-30 13:45, Stephen J. Turnbull wrote:
Stephen J. Turnbull writes:
> Putting that recipe as is in the developer docs also doesn't make > that much sense to me, as developers are expected to have full > clones of the components they're working on. On the other hand > something that points at the dev's local repos of the Mailman Suite > components does make a lot of sense to me.
That would be somewhere in the neighborhood of mailman/src/mailman/docs/install.rst.
Steve
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to teward@thomas-ward.net
participants (5)
-
Mark Sapiro -
Stephen J. Turnbull -
Thomas Krichel -
Thomas Ward -
Washington Odhiambo