[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>> The point is that the "release" tarball should generate the same
>> environment that the developers routinely work in;  otherwise, we leave
>> the poor suckers who install from it stuck with whatever bugs are caused
>> by the difference.
> 
> Ok. I'll note that Python eggs don't fulfill that goal of having a
> development area look like a package or an installed version either.

When we get there, I think the developer will install a single meta-egg,
which then pulls down and installs the others.  At that point, she will
be working in the same environment as everyone else.  When she wants to
modify a package, she will check it out separately and run the 'develop'
command, which will force the checkout onto her path as a "source egg".
Maybe we'll even have a script available which makes this a simpler process.

>> I'll agree that these items ought not to be in the Zope2 tree:  fixing
>> that *in the checkout* would be a worthwhile effort.
> 
> Indeed; in fact, we always wished they hadn't been there in the first
> place. Of course, in the end we hope that zope.app won' thave to be in
> Zope 2 at all anymore.

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).

>> The simplest approach I can see to that would be:
>>
>>   - On the Zope3 side, make it a rule that 'zope.app' contains only
>>     packages, not modules, converting the existing modules into
>>     packages with '__init__.py' corresponding to the current modules.
>>     Move the corresponding tests down into the new packages, as well.
>>     Currently, that would involve changing the following:
>>
>>       o zope.app.datetimeutils
>>
>>       o zope.app.decorator
>>
>>       o zope.app.servicenames
>>
>>       o zope.app.timezones
>>
>>     Alternatively, if any of those modules is not used in Zope2
>>     (it appears that 'datetimeutls' is the only one so used, except
>>     that it uses 'timezones'), we could leave them alone.
>>
>>   - Make the 'app' directory on the zope2 side a non-external,
>>     containing its own externals pointing to the packages we want
>>     to ship with Zope2.
> 
> Sounds like the simplest approach indeed. I'm +1. I'm -1 on moving
> anything around other than turning modules into packages, though. Moving
> things around bares risks of breaking something. We can't afford that
> within a stable release series. Not moving the tests won't be a problem
> because zope.app tests aren't run in Zope 2 anyways. If they were run
> we'd get lots of failures anyways, because zope.app stuff is quite
> interwoven.

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.

All unit and functional tests pass on that branch, with identical
results to the 3.2 tree.

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.

> Also note that all of the above have been deprecated in Zope 3.3/2.10
> (datetimeutils, decorator and timezones have been moved to the zope.*
> level, servicenames has been made obsolete).

Yup, the same general approach should work in the 2.10 tree.

>> I don't think this should be too hard, except for the fact that I don't
>> know how to run the functional tests on the Zope3 side:
>>
>>   $ ../bin/python2.4 test.py -m zope.app
>>   Running unit tests:
>>     Ran 3659 tests with 0 failures and 0 errors in 52.782 seconds.
>>   Running zope.app.testing.functional.Functional tests:
>>     Set up zope.app.testing.functional.Functional
>>   Traceback (most recent call last):
>>   ...
>>     File
>> "/home/tseaver/projects/Zope-CVS/Zope-3_2-branch/src/zope/configuration/xmlconfig.py",
>> line 394, in openInOrPlain
>>       fp = open(filename)
>>   zope.configuration.xmlconfig.ZopeXMLConfigurationError: File
>> "/home/tseaver/projects/Zope-CVS/Zope-3_2-branch/zopeskel/etc/ftesting.zcml",
>> line 20.2-20.40
>>       IOError: [Errno 2] No such file or directory:
>> '/home/tseaver/projects/Zope-CVS/Zope-3_2-branch/zopeskel/etc/securitypolicy.zcml'
> 
> Looks like you forgot to run 'make' to get the ZCML stuff installed into
> zopeskel...?

Hmm, I tried './configure --with-python" but there wasn't one, 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. ;)


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEnaym+gerLs4ltQ4RArIBAKCQSoCsS+PaAZPl4qMECiUv+fyiVQCfSVEC
3PTUmM6An/+ULklZcre8Cu0=
=IYhP
-----END PGP SIGNATURE-----