[Zope-dev] Re: Windows Binaries for 2.8b1

[Tim Peters]

[Tim Peters]
>> Someone with setup.py courage needs to step up to the plate then.  The
>> Windows build process is way hard enough to follow already without
>> adding reams of arbitrary new makefile cruft to paper over setup.py
>> bugs.  Perhaps someone on Linux could volunteer to run Zope trunk
>> tests from the result of doing "setup.py install ...", and add missing
>> files to setup.py until that works.  The WinBuilders tests can't
>> possibly work either so long as setup.py neglects to install necessary
>> files.

[yuppie]
> Done. (besides the Zope 3 failures)

Thank you!

> I did that more than once,

Did what more than once?

> but why can't people clean up after themselves?

Which people, cleaning up what?  Sorry, I'm not following this.

> AFAICS two things could help them:
>
> - giving feedback by running nightly test on a not-in-place installation

That would be helpful.

> - reducing the need for setup.py updates by switching to the Zope 3
> setup code

I think this gets worse with Zope3 code, and especially when mixed in
with Zope2.  Zope3 still uses setup.py for testing from a checkout,
but uses zpkgtools for building a distribution:  those two subsystems
have nothing in common, and get out of synch with each other.  It
would be better if Z3's setup.py used zpkgtools too, but it doesn't
now.  In any case, nothing in Z2 (including WinBuilders) knows
anything about how to live with zpkgtools now.

For Zope 2.8, there may not be a realistic alternative to teaching
Zope 2.8's setup.py how to install the Z3 bits in Zope 2.8.  It
already does this for other pieces.  For example, ZODB 3.4 (which Zope
2.8 uses) inherited the same setup.py-vs-zpkgtools schizophrenia from
Zope3, but Zope 2.8's setup.py learned how to install ZODB 3.4
independent of that (indeed, ZODB's own setup.py has never been part
of any Zope checkout that I know of).