On Sat, May 25, 2002 at 05:07:13AM -0700, Steve Freitas wrote:
> > I am pretty sure that the mxDateTime isn't "stock" in any of the python
> > versions.
It's definitely not part of Python's standard library. Python has an
extremely high standard for what is allowed into the standard library,
to avoid clutter that looks good at the time but then gets depreciated
later. It has to be (1) obviously THE best solution, (2) something the
Python team is willing to take over maintenance of (except the new xml
package, which is maintained by a third party). Of course it's not
perfect. String, regex, ftplib and xmllib got into the standard library
even though much better alternatives were found later.
> You can get it (with a bunch of other potentially useful stuff)
> > at: http://www.egenix.com/files/python/ (it's in the BASE package).
> In RedHat 7.3, mxDateTime is included standard in Python 1.5.x, but not
> Python 2.2.
Of course, Red Hat is merely an aggregator of software, so in a certain
sense it doesn't matter what they choose to package with each Python
version. It would be worth notifying Red Hat of this significant
oversight in the usability of their Python 2.2 suite, however.
Also, check the Egenix site to see if they've made their own RPMs.
Debian has python[version]-egenix-mxdatetime for Python 2.0 through 2.2.
I deal with the RPM/DEB availability problem by compiling it all myself.
Attached are 'install' and 'reinstall' shell scripts that compile and
installs Python and all the packages I need in one step. Of course it
needs tweaking every time a new version of something comes out, but it
provides a reminder of how I built it before. ('reinstall' skips the
time-consuming Python configure and make, and a couple other
differences.) The next time I revise these scripts, they'll be in
> If this tends to be common procedure on other distros, and Webware continues
> to expect to have it, perhaps it ought to be included in the Webware distro.
> Otherwise, it sets a precent for having to chase down a bunch of third-party
> modules to get things working, which complicates life for the poor guy who
> just wants to give it a quick spin.
That's a general problem for Python applications requiring third-party
packages, and not something Webware can necessarily solve on its
own. If there comes a point that we have to bundle packages like
mx.datetime, we'll have to consider that:
1) Some people (newbies) will want it included so that they can install
everything in one step.
2) Others already have some or all of those packages installed, and
would like to use those versions.
3) Some who already have those packages don't even want them
cluttering the Webware source.
It's a tradeoff because the desires are mutually exclusive. Of
course, it's also possible that a package's license might not allow
us to bundle it.
I actually like the Zope idea of bundling a preconfigured version of
Python. Even though it looks like a waste of disk space and memory,
it's valuable because it it insulates Zope from the version of Python
and packages installed system-wide. Otherwise Zope would break if I
install an incompatible version of Python or delete some packages
Zope depends on, and this installation of Zope is "maintenance only",
meaning we don't upgrade it unless we have to. Perhaps in the future
when we have "batteries included" versions of Webware, we can package a
version with its own Python.
As an aside, the reason I can get away with home-compiling Python and
packages is because none of my essential Debian scripts use Python.
(Debian insists system scripts be written in the languages of the
base set: sh, bash, or a minimal version of Perl). I'd like to see
distros that depend on Python use a separate copy of Python for their
system scripts, so that one can upgrade the general version of Python
or compile it locally without worrying about breaking essential
As for the comment that Python 2.2 is the current version and everybody
should upgrade, as much as I agree with it in principle, it's not
practical in the real world. People have third-party applications (like
Zope or complex homegrown software) running, and they can't take the
risk that the application might break, even if the risk is small.
So they upgrade at certain discrete points, such as when they are
revising that big application anyway. As a non-Python example, my
company has a binary-only Solaris program that runs on Linux 2.2 but not
on 2.4. So that server has to stay on 2.2 because it would cost several
thousand dollars to get a 2.4-compatible version.
-Mike (Iron) Orr, iron@... (if mail problems: mso@...)
http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol