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 Makefile format. > 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 system utilities. 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, [EMAIL PROTECTED] (if mail problems: [EMAIL PROTECTED]) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol
#!/bin/sh -ex # Compiles and installs Python and third-party packages. # # For final versions of Python, PYTHON_VERSION and PYTHON_MAJOR_VERSION will # be identical. For alphas/betas/release candidates, PYTHON_VERSION should # include the a1/b2/c3 suffix but PYTHON_MAJOR_VERSION should not. PYTHON_VERSION=2.2 PYTHON_MAJOR_VERSION=2.2 GENERIC_PREFIX=/local/opt/Python PREFIX=/local/opt/Python-$PYTHON_VERSION LIBDIR=$PREFIX/lib/python$PYTHON_MAJOR_VERSION/site-packages DOCDIR=/local/doc/Python-$PYTHON_VERSION-packages/ MX_VERSION=2.0.2 MYSQLDB_VERSION=0.9.1 IMAGING_VERSION=1.1.2 OPTIK_VERSION=1.3 PYRXP_VERSION=0.7 [ -e $GENERIC_PREFIX ] && rm -f $GENERIC_PREFIX ln -s $PREFIX $GENERIC_PREFIX # Python cd Python-$PYTHON_VERSION ./configure --prefix=$PREFIX make make install cd .. # Egenix MX Tools cd egenix-mx-base-$MX_VERSION python setup.py install cd .. # MySQLdb cd MySQL-python-$MYSQLDB_VERSION perl -pi -e 's/thread_safe_library =.*/thread_safe_library = YES/;' setup.py grep thread_safe_library setup.py # XXX mysqlclient_r python setup.py build python setup.py install cd .. # Imaging cd Imaging-$IMAGING_VERSION cd libImaging ./configure make cd .. make -f Makefile.pre.in boot make [ -e $LIBDIR/PIL ] || mkdir $LIBDIR/PIL cp PIL/* _imaging.so _imagingtk.so $LIBDIR/PIL cp PIL.pth $LIBDIR cd .. # Optik cd Optik-$OPTIK_VERSION python setup.py install cd .. # pyRXP cd pyRXP-$PYRXP_VERSION LIBERROR=0 python setup.py build LIBERROR=0 python setup.py install cd ..
#!/bin/sh -ex # Reinstalls Python and third-party packages. # # For final versions of Python, PYTHON_VERSION and PYTHON_MAJOR_VERSION will # be identical. For alphas/betas/release candidates, PYTHON_VERSION should # include the a1/b2/c3 suffix but PYTHON_MAJOR_VERSION should not. PYTHON_VERSION=2.2b2 PYTHON_MAJOR_VERSION=2.2 PREFIX=/local/opt/Python-$PYTHON_VERSION LIBDIR=$PREFIX/lib/python$PYTHON_MAJOR_VERSION/site-packages MX_VERSION=2.0.2 MYSQLDB_VERSION=0.9.1 IMAGING_VERSION=1.1.2 OPTIK_VERSION=1.3 PYRXP_VERSION=0.7 # Python cd Python-$PYTHON_VERSION make install cd .. # Egenix MX Tools cd egenix-mx-base-MX_VERSION python setup.py install cd .. # MySQLdb cd MySQL-python-$MYSQLDB_VERSION python setup.py install cd .. # Imaging cd Imaging-$IMAGING_VERSION mkdir $LIBDIR/PIL cp PIL/* ?_imaging.so _imagingtk.so $LIBDIR/PIL cp PIL.pth $LIBDIR cd .. # Optik cd Optik-$OPTIK_VERSION python setup.py install cd .. # pyRXP cd pyRXP-$PYRXP_VERSION LIBERROR=0 python setup.py build LIBERROR=0 python setup.py install cd ..
