Daniel,

> >	Stop/start everything is not strictly necessary, but since you
> >build the entire system as one package, it's impossible to say what to
> >stop or start.  As I recall, there are init.d scripts you could use to
> >stop/start only the things you are changing.  Again, this is a
> >safety/convenience tradeoff.
> I don't think it's eups's responsiblity to care about the internals
> of a package.

	Nope, definitely not.

> If you ask a package to "stop", the best thing for it
> is to stop everything that is started when you "start" the package.

	Exactly the safety/convenience tradeoff I was talking about.
The behavior you describe is safe, but not convenient.  Note that eups
is not responsible for starting or stopping packages.

> I think Jacek is just pointing out that he has a recipe to get
> things going, but his recipe says to do x, y, and z in sequence, to
> compile and get things installed. He doesn't need to do all of x, y,
> and z each time, so he'd like to invoke something more lightweight
> (that probably reuses some logic from x, y, or z).

	These are the init.d scripts, I think.

> >	If you built Qserv as a set of packages instead of as a single
> >package, it could be easier to manage this in a safe manner.
> True, but we have conceptually *one* system. It has distinct moving
> parts. This one system needs tools to integrate those parts more
> tightly and to manage their operation.  And the management of those
> parts will be part of the system, though it is a part we have not
> really written yet.

	The question is whether you provide (internal) interfaces that
allow third-party code to manage that integration (underneath your "one
system" view) or insist that you write all that code.

> I don't think Jacek is asking to do what he wants through "eupspkg
> -er decl". It doesn't have to involve eups at all (though it might
> need to be eups-aware).

	No, "eupspkg -er decl" just names an installed version and makes
it accessible to "setup".  It shouldn't be starting anything (or
configuring anything or doing much of anything at all).

> We want to tighten the feedback loop of run-edit-compile-run.

	I understand.  The main LSST Stack, because it's client-side
code and because its source root (after building) is usable as a package
root, has this loop:

setup -r .
edit
scons
run
edit
scons
run
...

(Note that this trades off reproducibility for convenience, as there's
no way to retrieve the build products of the first scons.)

Because you have server-side code, I don't think you can make Qserv
development this easy, but you definitely can come closer than you are
now.  Separating out the concept of an installation (compiled software
in a well-known location) from an instance (a configured, runnable
system) is the first step.  Providing interfaces to control components
of the instance is another step.

-- 
Kian-Tat Lim, LSST Data Management, [log in to unmask]

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1