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
Thomas Ward via Mailman-users writes:
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."
I would prefer not to suggest that people can do development without cloning at least the relevant git repo. I would have the disclaimer be something like
Occasionally ongoing development of dependencies causes
incompatibilities with released packages on PyPI. These usually
get fixed quickly in the trunk. An alternative to patching
individual files that allows you to seamlessly return to the
release track is to do a pip install from the HEAD versions of
various Mailman packages. This also has the advantage that you
can tell us exactly what versions of Mailman packages you have
installed without having to track manual patching. The
disadvantage, of course, is temporarily installing "beta"
software.What Do Others Think?
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Thu, Apr 2, 2026 at 7:19 AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Thomas Ward via Mailman-users writes:
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."
I would prefer not to suggest that people can do development without cloning at least the relevant git repo. I would have the disclaimer be something like
Occasionally ongoing development of dependencies causes incompatibilities with released packages on PyPI. These usually get fixed quickly in the trunk. An alternative to patching individual files that allows you to seamlessly return to the release track is to do a pip install from the HEAD versions of various Mailman packages. This also has the advantage that you can tell us exactly what versions of Mailman packages you have installed without having to track manual patching. The disadvantage, of course, is temporarily installing "beta" software.What Do Others Think?
I think those who want to run bleeding-edge software must be able to find out the details by themselves as opposed to being told how to do it. Ordinary souls like some of us must contend with released versions, not beta :-)
-- 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:
I think those who want to run bleeding-edge software must be able to find out the details by themselves as opposed to being told how to do it. Ordinary souls like some of us must contend with released versions, not beta :-)
Sure, but this thread was occasioned by trying to run the released Mailman versions on a recent Debian, if I recall correctly. In any case, because of the removal of nntplib from Python 3.13, in that situation there are three plausible paths:
- Install Python 3.12 from source, and use that in your venv.
- pip standard-nntplib from PyPI
- run the HEAD version of Mailman core (at least)
In this case approach 2 is likely the path of least resistance, but this kind of thing could also happen with the distro-installed Django, etc, etc. It's also possible that the user who would normally prefer the stability of the recent versions might be attracted by new features in the expectation that the next release is close and this "beta" version is quite stable.
So I think the "pip from git" approach has occasional value-added to "ordinary souls".
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Thu, Apr 2, 2026 at 12:08 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Washington Odhiambo via Mailman-users writes:
I think those who want to run bleeding-edge software must be able to find out the details by themselves as opposed to being told how to do it. Ordinary souls like some of us must contend with released versions, not beta :-)
Sure, but this thread was occasioned by trying to run the released Mailman versions on a recent Debian, if I recall correctly. In any case, because of the removal of nntplib from Python 3.13, in that situation there are three plausible paths:
- Install Python 3.12 from source, and use that in your venv.
- pip standard-nntplib from PyPI
- run the HEAD version of Mailman core (at least)
In this case approach 2 is likely the path of least resistance, but this kind of thing could also happen with the distro-installed Django, etc, etc. It's also possible that the user who would normally prefer the stability of the recent versions might be attracted by new features in the expectation that the next release is close and this "beta" version is quite stable.
So I think the "pip from git" approach has occasional value-added to "ordinary souls".
In Africa there is a saying that loosely translates into "if a child cries to be given a razor blade, give it to the child. If the child injures themself with it, s/he will have learnt their lesson" So, yes, there are sould out there who'd feel they want bleeding edge features at the expense of stability or otherwise. Or they just love life on the edge. The documentation should be enhanced to let those people run the git versions, albeit with a big caveat on the life they're like to be facing.
-- 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]
participants (5)
-
Mark Sapiro -
Stephen J. Turnbull -
Thomas Krichel -
Thomas Ward -
Washington Odhiambo