Hello, Of course, we already can use mxDateTime in our own products. But there is a problem, both modules have the same name, if you write "import DateTime" you get the Zope's DateTime module. A solution is to rename the mxDateTime module directory from DateTime to, for example, mxDateTime, then use "import mxDateTime" and everything is fine. Unfortunetaly this could break other python programs. I've played for several hours with imp, __import__, sys, etc.. but haven't been able to import mxDateTime as it's installed. If somebody knows how to do it please let me know. We also could build a python product (a Zope component as Brian suggests), it would be just a copy of mxDateTime. This is not very elegant because you could need two copies of mxDateTime, one for the Zope and one for other python programs. And it wouldn't be so easy to install because mxDateTime has C code that needs to be compiled. Another posibility is to use a symbolic link: $ cd <INSTANCE_HOME>/Products $ ln -s <wherever the mxDateTime module is> mxDateTime And then use "from Products import mxDateTime". Windows users still would need to copy the directory. The (small) problem with this solution is that requires some work of the user/admin that would be nice to avoid. The following code automates the creation of the sym. link: import imp, os, string, sys filename = os.path.join(INSTANCE_HOME, 'Products', 'mxDateTime') if not os.path.isdir(filename): ## Find the path to the mxDateTime module path = filter(lambda x, find=string.find: find(x, 'zope') == -1, sys.path) file, pathname, description = imp.find_module('DateTime', path) ## Create the symlink os.symlink(pathname, filename) from Products import mxDateTime But I still don't like this solution. If somebody comes to something better please let me know. Improvements to that code are also very welcomed, I want to use mxDateTime for the upcomoing new version of the CalendarTag. Also, perhaps DC could do something to avoid the name conflict for a future Zope release, :) best regards, jdavid
Note the "DC needs to decide..." only applies to what we decide to integrate (and thus sign up to maintain, at some level) into the core. One of the key goals of our long-term strategy of becoming much more component-oriented is that the "marketplace" (aka the community) decides what the best component is for a given task.
And we do not have to wait for the full component story to land for this to happen; as noted, I'm sure someone could come up with a product that "componentizes" mxDateTime in some way so that people who prefer it can use it easily.
Time and de facto usage would then tell whether we (DC) should consider some sort of transition - and we can learn whether that would be a good idea without inconveniencing those who prefer to continue using the built-in DateTime in the meantime.
Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com