Just as a data point. A lot of autoconf projects (the ones that made "./configure; make; make install" famous) don't just run like that from a checkout, but they are never more than 2 steps away from that. The process for a checkout is usually more like "./autoconf; ./automake; ./configure; make; make install" My point is: I don't think there's anything wrong in the install procedure being different between the checkout and the tarball, but it should never take more than a couple of fixed (and documented) steps to convert a checkout to a tarball-equivalent environment, where "./configure; make; make install" would work. Cheers, Leo.

Jim Fulton wrote:

I'd like to step back and see if we can agree on what is driving the desire for "make install". I'll note that one reason is that it worked this way before, but I don't think that that is a good enough reason to delay the release.

I'll note one use case:

- A Zope deployer wants to deploy an unreleased version of Zope because they need some feature or bug fix that hasn't been released yet.

Can anyone think of other use cases?

* A Zope developer wants to test multiple Zope setups with the same checkout. The most important bit to me is not actually a use case per se. It's "don't surprise". Having the checkout be different from a release tarball will make it harder for people used to working with the release tarball to switch to working with the checkout (and vice versa, but that's less common). This makes it harder for people to dive into core development on occasion. We want to make it easy for people, not harder. It's not a big barrier, but it is a barrier. I mostly work with release tarballs while developing, but sometimes I need to work with a checkout. In that case I want to suddenly have to switch to a different way of doing things. A bit that's related to this, and also not exactly a use case, is "don't be special". Being different in the way checkouts versus releases work is not Zope's core business of being a web application platform. It's another doubletake for people who just want to try things out, and may stop some people from getting there; we should lower the amount of persistence needed to get into Zope by random python developers as much as possible. :) This possibly ties into a larger discussion on the way we layout our zope source repository -- people who are just interested in zope.interface and want to help develop it, say, have a barrier right now that could be avoided. Of course the ability to hand out release tarballs with zope.interface is even more important and we do have that, so that's great. We should probably be holding this discussion later, not right now, though. Regards, Martijn