[Zope-Coders] RE: [ZC] 586/ 2 Resolve "start script not setting INSTANCE_HOME"

[Charlie Reiman]

Yes, I get that. What I'm saying is maybe it should be set in 'start' since
you need it for separate instances anyway and it's harmless in the case
where you don't (assuming it is set correctly). It reduces the amount of
special things you need to do to create new instances. Since creating
separate instances is almost always the right way to go, it seems like
making this easier would be wise, especially since it doesn't harm unified
instances.

It is just a suggestion though. It's all up to you guys. I'm happy that you
had a look at it and got rid of the INST_HOME oddness which was just
confusing.

> -----Original Message-----
> From: Chris McDonough [mailto:chrism@zope.com]
> Sent: Friday, September 27, 2002 11:18 AM
> To: Charlie Reiman; Collector: Zope Bugs, Features, and Patches ...;
> mcdonc; klm; Brian; Caseman; _Resolved_ recipient
> Subject: Re: [ZC] 586/ 2 Resolve "start script not setting
> INSTANCE_HOME"
>
>
> INSTANCE_HOME was never set in any revision of any Zope-generated
> 'start' script.  Lots of magic goes on to infer SOFTWARE_HOME, but
> INSTANCE_HOME needs to be specified as an ennvar.
>
> - C
>
>
>
> ----- Original Message -----
> From: "Charlie Reiman" <creiman@kefta.com>
> To: "Collector: Zope Bugs, Features, and Patches ..."
> <zope-coders@zope.org>; "mcdonc" <chrism@digicool.com>; "klm"
> <klm@zope.com>; "Brian" <brian@zope.com>; "chrism"
> <chrism@zope.com>; "Caseman" <casey@zope.com>; "_Resolved_
> recipient" <zope-collector-monitor@zope.org>
> Sent: Friday, September 27, 2002 12:07 PM
> Subject: RE: [ZC] 586/ 2 Resolve "start script not setting
> INSTANCE_HOME"
>
>
> > Hmm... well, I don't know what to think of that. I do know that if
> you take
> > the 2.6b1 start script and change INST_HOME to INSTANCE_HOME, it
> works great
> > for in-place zopes and only requires retargeting of z2.py for
> separate
> > instances. I've never had to set SOFTWARE_HOME. Perhaps it is
> inferred
> > correctly within z2.py?
> >
> > > -----Original Message-----
> > > From: Collector: Zope Bugs, Features, and Patches ...
> > > [mailto:zope-coders@zope.org]
> > > Sent: Thursday, September 26, 2002 10:34 PM
> > > To: Charlie Reiman; mcdonc; klm; Brian; chrism; Caseman;
> _Resolved_
> > > recipient
> > > Subject: [ZC] 586/ 2 Resolve "start script not setting
> INSTANCE_HOME"
> > >
> > >
> > > Issue #586 Update (Resolve) "start script not setting
> INSTANCE_HOME"
> > >  Status Resolved, Zope/bug medium
> > > To followup, visit:
> > >   http://collector.zope.org/Zope/586
> > >
> > > ==============================================================
> > > = Resolve - Entry #2 by mcdonc on Sep 27, 2002 1:33 am
> > >
> > >  Status: Pending => Resolved
> > >
> > > Actually, the script should not set INSTANCE_HOME at all.  The
> > > default 'start' script is always meant to be run from a
> > > SOFTWARE_HOME.  If you need to run in an INSTANCE_HOME setup,
> you
> > > need to specify both SOFTWARE_HOME and INSTANCE_HOME in a
> > > (custom) 'start' script.
> > >
> > > The references to INST_HOME in this script have been around
> since
> > > Dec. 12, 2000.  I'm baffled by why this script exports
> INST_HOME.
> > >  It only does so if the Python version you're running is a 2.X
> > > version, otherwise it references 'PYTHONHOME' instead.  There's
> a
> > > cryptic comment in the code that generates the script something
> > > to the effect that "PYTHONHOME is bad under 2.X".   Shrug.
> > >
> > > INST_HOME appears nowhere else in the Zope source, so I've
> > > removed references to it from the script generator under the 2.6
> > > and trunk Zope branches.  The references won't appear in the
> > > start script anymore, hopefully preventing any confusion.
> > >
> > > Thanks for the report!
> > >
> > > - C
> > >
> > > ________________________________________
> > > = Request - Entry #1 by Anonymous User on Sep 24, 2002 8:26 pm
> > >
> > > The start script as generated by make_instance sets INST_HOME,
> > > not INSTANCE_HOME. So new instances will end up use the old
> > > database. This is immediately obvious but it should be fixed.
> > > ==============================================================
> > >
> > >
> >
> >
>
>