Examples can have command-line arguments, but unit tests must not.

As we start building more Pythonic and hence complex wrappers around C++, testing at the C++ level may become more important. I wouldn't want to rule out finding package/product directories from C++.

But a simple wrapper can provide command line arguments to the unit tests, so I don't think that that's fundamental.

After some more thought, I'm thinking the following:

• Tests are intended to be self-contained, not requiring anything in another package.
• Other inter-package references should use mechanisms such as the Python or C++ namespaces, or possibly custom mechanisms for locating things like config defaults/overrides.
• Tests can't always be self-contained because we want to share large, widely-useful input datasets, plus there's the large-files-in-git problem.

My conclusions:

• We should write all our tests assuming that they are self-contained, with any required data in a tests/data subdirectory.
• We should modify the tests/SConscript or more likely sconsUtils to provide functionality to locate the appropriate test data package (or more than one) and symlink it (them) into place.
• If the data is not available, tests that rely on it could be skipped or the build could fail (depending on context: install or CI build). A missing symlink would obviously reveal unskipped tests that are relying on the data.
• Since this is a special case, a general-purpose utils function in Python or C++ is not necessary or even desirable.

K-T I am not entirely happy with your conclusions.

I think our current system (using getPackageDir to get the path to a product) is a reasonable way to find config files and test data.

You suggest making symlinks for test data. I am unhappy with this because we end up with two different mechanisms to manage packages: eups and symlinks. This means learning two different systems, and what happens if they don't agree?

Even if we change to a package management system that uses symlinks, I don't think we should rely on the internal details of how packages are managed. Thus I'd still prefer a function such as getPackageDir that hides the details.

All that said, our current situation has one problem that might be worth fixing (preferably on a separate ticket): we have two implementations of the same function: lsst::utils::getPackageDir and eups.productDir (which is defined in sconsUtils, which I am unhappy about because it makes it hard to find the function). We have some use cases for a C++ version of this function; I'm sure we can manage without it, but the result is tests and examples that are harder to run or have to be rewritten. Is it worth the cost? I'm not convinced. One possible solution is to add a bit of C++ code to sconsUtils (just this one function). If we go that route then I suggest having the function be in the sconsUtils namespace.

My inclination is to not implement this ticket and leave things as they are for now.

I guess I wasn't clear. The symlink is not to manage packages. It is just something done by the tests/SConscript to set up the environment for tests; I'd actually expect the symlink to be removed after the tests have been executed. The point of the symlink is that no C++ function is needed to find any directories; the code can assume it knows exactly where its data is.

For examples, not tests, taking a command-line argument is a reasonable solution to avoiding this function.

That is how I took your symlink suggestion, except I didn't realize you intended to get rid of it after tests are run. I often run tests manually while working on packages, so getting rid of the symlink would be a hardship for me. On the other hand, leaving symlinks around results in the unfortunate and potentially confusing dual management of packages (eups and symlinks) that I mentioned above.

Also, how easy is it to find the path of the current file in C++? I would have thought it nearly impossible. Yet it is a definite advantage to be able to run a unit test from anywhere. Certainly it is common to manually run them the root dir of the package and the tests dir. Yes sconsUtils only does one of these, but users may do both, or from even stranger paths.

I suppose we could prohibit C++ tests from reading data files, but that seems draconian. Lack of getPackageDir in C++ also makes C++ examples clumsier to use because they cannot have useful arguments (though I admit that C++ examples are rare).

Implementing getPackageDir in C++, although not ideal, seems cleaner to me than anything else I've seen so far.

Ah, you're right about manually-executed tests. I was only thinking about running them as part of the build. So much for that idea.

C++ getPackageDir does seem like the best answer for now.

We decided to keep it, at least for now, for the reasons mentioned in the discussion.