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

[Tres Seaver]

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

Tres Seaver wrote:
> 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've now done the same work on a branch for that tree:

 [/home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10]
 $ head .svn/entries
 <?xml version="1.0" encoding="utf-8"?>
 <wc-entries
   xmlns="svn:">
 <entry
    committed-rev="68857"
    name=""
    committed-date="2006-06-26T21:16:14.182239Z"

url="svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-retire_zpkg-2.10"
    last-author="tseaver"
    kind="dir"


Note that here I used the contents of 'zope.app' as installed by the
2.10b1 tarball, which has at least one of the packages in it ('wfmc')
which Philipp said should be excluded for 2.9.

AFAIK, both of these branches are ready for merging to their respective
branches (and to the trunk, for the 2.10 version).

Comments?


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

iD8DBQFEoFIz+gerLs4ltQ4RApTFAKCRpYarfrxQcBkZAaTmFqYWemQ6ZQCghVpS
aYhIXCIMVqta0V+LH9gD7Tc=
=V2vf
-----END PGP SIGNATURE-----