Tres Seaver wrote:
That will be good. Even after eliminating the list you provided (see below), there is still a lot of stuff in zope.app which is irrelevant to Zope2 (I think).
Agreed. By the way, I just compated a Zope 2.9.3 install with your tarball. The same comparison should be done again with the Zope 2.10b1 tarball as other zope.app packages might've made it into the Zope 2.10 release line. At least with explicit externals in zope.app we can avoid more zope.app junk sneaking into Zope 2 much better.
I've created a new branch from the 3.2 branch which makes the changes I proposed: i.e. 'datetimeutils', 'timezones', and 'decorators' become packages, and their tests move from 'zope/app/tests/' to their own 'tests' subdirectory (none of those tests exported facilities used by any other tests.
Ok.
I have also morphed the 'zope.app' package in my 'tseaver-retire_zpkg' branch to point into this new branch, eliminating the "dead" packages you described. The only "forked" code is the empty __init__.py, which seems an acceptable tradeoff. I added an EXTERNALS.txt file which documents the intended links.
BTW, a small nit of mine with subversion: can anybody tell me how to find the revision in which a directory was moved / removed, preferably via the web interface? Subversion doesn't seem to expose a way to ask about a name which, like the "man upon the stair" isn't there any more.
I usually google to find the checkin email :).
Hmm, I tried './configure --with-python" but there wasn't one
Right, it's a checkout. What's there to configure? (Besides the Python executable).
so I didn't even look for the Makefile. How do Zope3 developers cope with the possibility that the user may need / want to use a different Python? Running 'make PYTHON=/path/to/my/python' works, but seems a little hard-core for the make-averse crowd that hands out on #zope3-dev. ;)
Heh, but that's how we do it :) Philipp