"Barry A. Warsaw" wrote:
>
> >>>>> "MAL" == M <mal@lemburg.com> writes:
>
> MAL> "Barry A. Warsaw" wrote:
> >> [distutils --root hackery]
>
> MAL> Why not use the subpackage approach I suggested ?
>
> MAL> It keeps the std lib in a sane state (meaning that the std
> MAL> lib installation only depends on the Python installation and
> MAL> no other hacks on top of it).
>
> MAL> Since you'll have to ship the complete package anyway, I
> MAL> don't see any win in installing over the std email
> MAL> package. If that's what you really want, I'd suggest to
> MAL> provide the updated email package as separate download and
> MAL> then test inside Mailman for the new version.
>
> I'm fine with installing in a Mailman specific location, but I still
> want to use as much of the distutils machinery as possible.
>
> It looks like
>
> python setup.py install --home=/some/path
>
> gets close enough.
No, no, no :-)
What I am suggesting is to put the email package *inside* the
Mailman package:
Mailman/__init__.py
...
email/__init__.py
...
And then use "from Mailman import email" in Mailman source
code. That's clean, doesn't interfere with the std lib
and it's all your's ;-) (meaning that you have complete
control over what email does in the Mailman context).
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Software: http://www.egenix.com/files/python/
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