Project: datamanagement
Issue DM-1338: Make QSERV_RUN_DIR scripts able to detect qserv install paths using eups
Ticket related to Mario email (subject: [QSERV-L] Some points/actions from the discussion today) : Making your "qserv data" directory independent of where qserv is installed I think this is a big one, and largely independent of EUPS. You have a problem where you want to use one set of test data potentially with different qserv binaries (not at the same time, of course). I'd argue you should refactor the scripts generated by qserv-configure to either: * get _all_ their information about various paths from a _single_ file, for example, from etc/paths.cfg.sh. Then you can easily regenerate just that file when you need to switch to a different qserv (or zookeper, or what not), or... * refactor the generated scripts to learn from the environment which binaries to run. I.e., if $QSERV_DIR is defined, use that qserv, etc. This will let you switch binaries by simply setup-ing the new one with EUPS. The two are not mutually exclusive -- e.g., all of this logic could be in etc/paths.cfg.sh, and depending on whether this is a development build or a "non-EUPS" build, it can either pick up the paths from the environment or hardcode them. Assuming you did that, your development loop may look something like this: {code} # assuming that qserv-configure.py has already been run # in ../qserv-run # do something with qserv-a clone cd qserv-a setup -r . ... do some edits ... scons # now do the tests cd ../qserv-run ./bin/qserv-start.sh ... do tests ... ./bin/qserv-stop.sh # now switch to qserv-b clone cd ../qserv-b setup -r . # and do the tests again cd ../qserv-run ./bin/qserv-start.sh ... do tests ... ./bin/qserv-stop.sh {code} that is, as qserv-start picks up the relevant products from the environment, there's no need to rebuild/reconfigure the qserv-rundirectory each time.
Story points: 7