Re: [IMP-dev] [IMP-commits] r1054 - trunk/kernel/pyext/IMP
Overall I don't really see the benefit of such a feature unless it is going to be used to make it so you can run tests from any cwd (since the correct one is nonobvious) or to separate the test data from the tests so we dont have 4 copies of single_protein.pdb around. And in either of those cases the current directory is a bad default as you have to be elsewhere for almost any other operation (and the commit log messages was poor).
Also, what happened to posting changes to how things work on imp-dev for comment?
On Dec 18, 2008, at 6:58 PM, Notification of IMP commits <imp-commits@salilab.org > wrote:
> Author: ben@SALILAB.ORG > Date: 2008-12-18 18:58:41 -0800 (Thu, 18 Dec 2008) > New Revision: 1054 > > Modified: > trunk/kernel/pyext/IMP/test.py > Log: > Default to current directory if TEST_DIRECTORY is not set. > > > Modified: trunk/kernel/pyext/IMP/test.py > =================================================================== > --- trunk/kernel/pyext/IMP/test.py 2008-12-18 22:28:10 UTC (rev > 1053) > +++ trunk/kernel/pyext/IMP/test.py 2008-12-19 02:58:41 UTC (rev > 1054) > @@ -18,7 +18,9 @@ > > def get_test_file(self, filename): > """Get the full name of a file in the top-level test > directory.""" > - path = os.environ['TEST_DIRECTORY'] > + # If individual tests are run manually, assume they are in > + # the current directory: > + path = os.environ.get('TEST_DIRECTORY', '.') > return os.path.join(path, filename) > > def assertInTolerance(self, num1, num2, tolerance, msg=None): > > _______________________________________________ > IMP-commits mailing list > IMP-commits@salilab.org > https://salilab.org/mailman/listinfo/imp-commits
Daniel Russel wrote: > Also, what happened to posting changes to how things work on imp-dev for > comment?
Unless I am missing something, this is not changing how things work; tests have always read any input files from the current working directory. Personally, I would rather tests did not read *any* input files (or if they really needed a file in a specific format, it could be embedded in the Python script itself, and read via StringIO or dumped out to a temporary file via tempfile and then read back in).
Ben
On Dec 19, 2008, at 4:46 PM, Ben Webb ben@salilab.org wrote:
> Daniel Russel wrote: >> Also, what happened to posting changes to how things work on imp- >> dev for >> comment? > > Unless I am missing something, this is not changing how things work; > tests have always read any input files from the current working > directory. Personally, I would rather tests did not read *any* input > files (or if they really needed a file in a specific format, it > could be > embedded in the Python script itself, and read via StringIO or dumped > out to a temporary file via tempfile and then read back in). While I think that would be nice in theory to not read inputs, I think sticking a whole pdb in a .py would obscure the test code.
I think defining the path to imp root path in imppy and using paths relative to that in the tests might be an improvement since we are pretty much stuck using imppy for the time being and that would make it so it doesn't matter what your current directory is.
Daniel Russel wrote: > While I think that would be nice in theory to not read inputs, I think > sticking a whole pdb in a .py would obscure the test code.
Well, that's an extreme (and hopefully rare) case. True, it would obscure the test code. One solution is to stick it in a separate Python module and import that. But sure, for PDB files it probably makes sense to read them off the disk.
> I think defining the path to imp root path in imppy and using paths > relative to that in the tests might be an improvement since we are > pretty much stuck using imppy for the time being and that would make it > so it doesn't matter what your current directory is.
That would break my use case, which is: when a bug is fixed, I add a test case for it, and run that test case both with an 'old' version of IMP, generally that in /diva1, and with the 'fixed' version, to make sure that the old version fails and the fixed version works. Such out of tree runs would obviously fail if tests were always relative to imppy.
I don't much like having inputs for tests in a 'global' directory, since that way it is difficult to keep track of which module uses which inputs, and people that work in just their own module would have to worry about things outside of their module. (e.g. sharing a foo.pdb between two modules could cause one module to break unexpectedly if the other module's owner changes foo.pdb for a change to their own testcases.) The overhead of having multiple copies of these inputs isn't great, and we can always explicitly share files by creating symlinks - that way it's obvious that if module 'foo' symlinks to foo.pdb in core's tests, foo's author will be affected by changes in core, but not vice versa.
Per-module test inputs currently live in modules/foo/test/. It would be pretty simple for me to modify unit tests to always read files from this directory regardless of their cwd. Alternatively, maybe it would be tidier to put these inputs in their own subdirectory, e.g. modules/foo/test/data/. Opinions?
Ben
> Per-module test inputs currently live in modules/foo/test/. It would be > pretty simple for me to modify unit tests to always read files from this > directory regardless of their cwd. Sounds great. I was attempting to do that but couldn't figure out anything better than setting the root in imppy.sh (and without requiring someone to use run_all_tests). Plus, anything which reduces the dependency on imppy.sh is a good thing.
participants (2)
-
Ben Webb -
Daniel Russel