>>>>> "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. This will install the email package into
/some/path/lib/python and I can easily arrange for that to be in the
right place on sys.path, at least for the mail program and the cgi
program.
The command line scripts are a bit trickier because you can't wheedle
your way into Python's startup machinery without 1) telling your users
to setenv PYTHONPATH (yuck) or 2) importing a path-hacking module
before any that require the override location. Since I already have
to do #2 anyway, this isn't much of a problem, except that some
imports will have to be rearranged. It also makes things a little
trickier when a user does eventually upgrade to Python 2.3, which will
obviate the need for the enhanced package (hopefully).
Like everyone else, I'm sure I'll eventually just end up shipping my
own complete Python distro to make sure it's got exactly what you
need. ;)
-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