[Zope3-dev] Re: package-includes query

[Tres Seaver]

Jim Fulton wrote:
> 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.

Right, but I particularly want *only* to update the software, not the 
site-local policy choices.  This is why we have the various '.in' files 
lying about;  they represent "default" policies, and are used to create 
the (non-version-controlled) policy specifications.

> 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.

Even in Zope 2, there is a useful distinction between the software (the 
bits under '$checkout/lib/python') and the rest.

>> 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.

Right, so lets make it easy (maybe even the default thing) to work from 
a non-version-controlled instance, whose sofware remains within the 
checkout.

> 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.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com