[Zope-dev] What use cases are driving "make install" from a checkout?

[Martijn Faassen]

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