[ZODB-Dev] Includes patch: [johan@gnome.org: zodb3 trunk patch]

[Tim Peters]

[Christian Robottom Reis]
...
> Precisely. We work from SVN trunk, everywhere else is too boring <wink>.

Absolutely -- and I encourage living in exciting places <wink>.

[Tim Peters]
>> I'm not sure it's a good thing that the code to build releases no longer
>> has any connection to the code used for day-to-day development, but
>> that's the way it is for now.


> I had no idea this was the case. Basically, you want to ensure that
> headers are installed with both SVN trunk checkouts and the tarball
> releases; otherwise people writing extensions have a hard time getting
> their software compiled on developer installations.

I agree.  I really didn't know how "fractured" the ZODB build process had
become before I investigated your report; of course I did the checkin to
setup.py (on ZODB trunk and 3.3 branch) last week.  And Fred fixed zpkg too.
I expect them to get out of synch again, though (why?  just because storing
the same info in two places in two different formats *always* gets out of
synch again).

> It's indeed a shame that both systems diverge; I wonder if it is a
> fixable problem.

This has the feel of a good idea that got dropped somewhere before
completion, because it turned out to take more work than anyone planned on,
and other problems became more pressing.  IOW, it has the feel of every
non-trivial software plan I've ever seen <0.7 wink>.

I'm not sure this isn't intentional, though.  I've noticed all along, when
building the Windows installers for the Zope X3 releases, that the tarball
distribution looks nothing like a checkout tree (indeed, I needed Fred's
help at first to find the code in the tarball!), so we have to run the tests
all over again from the unpacked tarball, and then all over again all over
again after running an install step (which rearranges stuff yet again so it
doesn't look much like the unpacked tarball anymore either).

I think this may follow from:

<http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Packa
gingProposal>

where there's desire expressed to make the Zope 3 repository structure
independent of how Zope 3 gets deployed ("Liberate the Zope repository from
having to reflect distribution or packages status").

OTOH, it also says "It should remain possible to check out the Zope 3 CVS
module, execute a simple build command and run Zope in place".  I think we
achieved that now, but in an illusory way, by keeping all of the old
setup.py stuff around, and adding "use zpkg for releases" as a distinct new
system with no intersection.  Maybe that's where the project got dropped
last time it was worked on.

Whatever, it is what it is for now, and I won't be working on it in the
foreseeable future.