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

[Tres Seaver]

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

Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>>>> I believe that the extra flexibility which zpkg is intended to provide
>>>> (dependency-based subset distributions, primarily) would be better
>>>> served by moving Zope to use eggs,
> 
> Where are the eggs, btw?

Not part of this proposal.  I just want to use the same installation
machinery as Zope2 has always used, and let the egg stuff sort out later.

>> I will be ready shortly to merge this branch to the 2.9 branch, the 2.10
>> branch, and the Zope2 trunk.  Here is how I have tested it so far:
>>
>>   - All unit tests pass, with the same count (and deprecation warnings!)
>>     in my sandbox for this change as for the 2.9 head.
> 
> This doesn't surprise me. After all, you just tarred up the SVN export.
> zpkg actually only tars up what is explicitly selected to be released.
> Your tarball contains a few things that haven't been in Zope 2.9.x
> releases before, e.g.:
> 
>   - zope.app.boston
>   - zope.app.catalog
>   - zope.app.css
>   - zope.app.dav
>   - zope.app.debugskin
>   - zope.app.demo
>   - zope.app.fssync
>   - zope.app.homefolder
>   - zope.app.i18nfile
>   - zope.app.interpreter
>   - zope.app.locking
>   - zope.app.module
>   - zope.app.observable
>   - zope.app.pluggableauth
>   - zope.app.presentation
>   - zope.app.pythonpage
>   - zope.app.recorder
>   - zope.app.schemacontent
>   - zope.app.securitypolicy
>   - zope.app.server
>   - zope.app.sqlexpr
>   - zope.app.styleguide
>   - zope.app.twisted
>   - zope.app.versioncontrol
>   - zope.app.wfmc
>   - zope.app.winservice
>   - zope.app.workflow
>   - zope.app.zopetop
> 
> Most of these
> 
> a) have either never released even in Zope 3 (this is the majority),
> 
> b) are sample things (like css, styleguide, demo, etc.) that are (for
> the most part) bitrotting in zope.app
> 
> c) are so much core to Zope 3 that they don't make sense in Zope 2 (such
> as twisted, securitypolicy)
> 
> While b) and c) might not do much harm, the fact that things in a) *are*
> released now *does* make a new feature. Even worse, most of the things
> in category a) *should not* be release because they're considered broken
> or unstable. I agree that zope.app is horribly trashed with junk that
> doesn't belong in there (probably doesn't even belong inside the Zope 3
> tree), but that's how it is right now. Just dumping it in a tarball
> isn't the way to go...
> 
> If it had been that trivial to NOT use zpkg back then, I certainly
> wouldn't have considered it at all...

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.

I'll agree that these items ought not to be in the Zope2 tree:  fixing
that *in the checkout* would be a worthwhile effort.  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.

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'


Ripping out the unused / unusable code which is sitting unused in the
Zope3 tree is *not* in scope for my proposal.


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

iD8DBQFEnZSz+gerLs4ltQ4RArw6AJ9LWK9/e3Roi68HDUxZppVENMKdRQCgk08A
FXL+LjWC0zVpWWXclbXWzX4=
=uSyp
-----END PGP SIGNATURE-----