>>>>> "MAL" == M <mal@lemburg.com> writes:
>> install --home=/some/path gets close enough.
MAL> No, no, no :-)
MAL> What I am suggesting is to put the email package *inside* the
MAL> Mailman package:
MAL> Mailman/__init__.py
| ...
| email/__init__.py
| ...
What I didn't say was s|/some/path|/path/to/Mailman|
so we're saying (nearly) the same thing.
MAL> And then use "from Mailman import email" in Mailman source
MAL> code. That's clean, doesn't interfere with the std lib
MAL> and it's all your's ;-) (meaning that you have complete
MAL> control over what email does in the Mailman context).
I could do this (and may) or I may use something like from
Mailman.pythonlib import email, which is my normal place to put
override modules.
It's moderately more appealing to put Mailman.pythonlib on sys.path
and just leave my "import email"'s alone. I know there are arguments
against doing it that way, but I don't want to have to change dozens
of files.
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4