[Zope3-dev] package-includes query

[Jim Fulton]

Tres Seaver wrote:
> Jim Fulton wrote:
> 
>> Tres Seaver wrote:
>>
>>> I just ran into this yesterday:
>>>
>>>   - I had moved a bunch of the "add-on" packages aside in
>>>     'package-includes', to verify that things still worked in
>>>     that case (e.g., I renamed 'pythonpage-configure.zcml' to
>>>     'pythonpage-configure.zcml.aside').  This was essentially
>>>     "policy" for my test site, and would be the natural way to
>>>     deactivate unwanted features.
>>
>>
>>
>> Why would you use an svn checkout for a test site?
>> I would think it would be better to use a beta release.
>>
>>>   - However, those files are under SVN, which means that I (or
>>>     somebody else) is likely either to check in such changes,
>>>     or else lose their policy choices, inadvertently.
>>>
>>> Maybe we need to port 'mkzopeinstance.py' over pretty quickly,
>>> and begin treating the SVN 'package-includes' as a "skeleton'.
>>> This would allow us to handle creation of a new 'principals.zcml'
>>> more cleanly, as well.
>>
>>
>>
>> There already is a mkzopeinstance, but it's intended to be used with
>> releases, not checkouts. I guess I'm not opposed to having one that can
>> be used without a checkout, although I can't see much point. I suppose 
>> the
>> reason to do this would be able to test against the trunk. Is that your
>> motivation?
> 
> 
> My actual motivation is that there was no tarball at the time I started 
> playing with the beta, only a tag. :) 

Hm, let me try to translate that. You weren't concerned about
testing the current trunk. If you'd has a release (tarball), that
would have met your needs.

 > I do think that the 'make
> inplace' instance *should* bind all packages into the instance, but I 
> think we could benefit from something like Zope 2.7's 'make instance', 

In Zope 3, the checkout is the instance.  This is based on the assumption
that if you have a checkout, you want, at a minimum, do an update and affect
a site based on a checkout.  The key here is that the software location is
the checkout. There's really no harm in having the instance location be different
than the checkout. Hm, I'm talkingmyself into having a working mkinstance in
a checkout. :)

I find Zope2's behavior, to be overly complicated. This complication arises
from the fact that a checkout and a release are essentially identical.

> which lets you initialize a new instance from within a checkout (or the 
> tarball distro).

But such an inplace instance has the problem that customizations (like changing
package includes) have the potential to be accidentially checked in.

In summary, I prefer to work from a checkout.  No special "make instance"
is needed for that, but I see the value of having a working bin/mkinstance
script that can mke a separate instance, using the checkout as it's software
location.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org