Here is a relevant bit from the Data Management HipChat room 2015-04-28

[4:23 PM] Russell Owen: I'm looking through the C++ functions provided by utils and I've found two that don't seem to be used anywhere: guessSvnVersion (no surprise) and stringToAny. The latter is not even documented, though it's easy to see what it does by reading its code. Can I remove these as part of DM-2635?

[4:26 PM] K-T Lim: Looks like the latter was expected to be used in FITS-reading code. OK with me to remove both.
(Should really have a quick RFC to make sure everyone knows, but since there are no references, I don't see how this could hurt, and it's easy to put back.)

[4:27 PM] Robert Lupton: As @ktl wrote stringToAny and it doesn't show up in anything I have checked out, it's good to delete. But in general we need a way to remove APIs

The fact that stringToAny is not documented means that it's easy to decide to remove it. If it had had a doc string, and thus appeared in doxygen, it'd be a harder case to make.

Even if it were in doxygen, as long as it's unused in our code and unlikely to be used by end-user code, I'd say it's a pretty easy case to make.

(My point about being easy to put back was that this doesn't necessarily even rise to the level of needing an RFC. Nevertheless, +1 from me.)

This may be obvious to everyone, but why is getPackageDir implemented in C++?

getProduct is used by some C++ tests and demos (all in the afw package, in case you want to look).

util had separate implementations in C++ and Python, and both were rather different. The C++ version raised an exception if the product was not found, which I prefer, but it had an unimplemented argument we don't need. I'm unifying them with one SWIG-wrapped C++ function getPackageDir that just takes the package name and does raise an exception if the package is not found

A better solution would be to remove the use of productDir from the examples (passing the filename on the command line?), but it probably isn't worth doing as part of this issue.

The tests are similar:

tests/background.cc:            afwdata_dir = lsst::utils::eups::productDir("afwdata");

tests/convolveGPU.cc:            string dataDir = lsst::utils::eups::productDir("afwdata");

tests/statistics.cc:            afwdata_dir = lsst::utils::eups::productDir("afwdata");

tests/testWarpGpu.cc:            string dataDir = lsst::utils::eups::productDir("afwdata");

and we should probably remove some (do we really need C++ tests for things we test in python?) and convert the others to accept filenames from argv[], also as another issue.

Russell Owen, thanks, I didn't realize that. Your solution seems fine, though I think it further illustrates the need to be able to easily call into Python from the C++ layer (even as a temporary solution until we get to doing something like Robert Lupton is proposing).

Bottom line, +1 from me!

I filed DM-2641 to handle the issue brought up by Robert Lupton.

The discussion seems to have converged with no serious objections.

This is a good example of even more code being moved to the C++ layer (especially in this case because it seems that if it wasn't for these tests the code could have stayed in Python land).