[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] [IMP-commits] r4751 - trunk/modules/restrainer/examples

On Feb 10, 2010, at 11:43 AM, Ben Webb wrote:

> On 02/10/2010 11:33 AM, Daniel Russel wrote:
>>> True, particularly in Restrainer's case where you have paths embedded
>>> in your XML files - you can't use get_example_path() there.
>> Can't you use relative paths there? eg the .xml file contains
>> "./foo.dat" (or just "foo.dat") which should search for the data file
>> relative to the input xml. Otherwise, either you can't relocate you
>> setup or have to always run it from the same directory relative to the
>> .xml file, both of which would be very annoying. Or perhaps I'm confused.
> I think you are confused - Elina is already using relative paths (e.g. 'input/foo.xml') but they don't work since the examples are run from the top-level directory - they need to be either 'modules/restrainer/examples/input/foo.xml' or 'build/doc/examples/restrainer/input/foo.xml' either of which would, if hard-coded in the XML, obviously preclude a user from running an installed example. Relative paths aren't relative to other files, of course, but relative to the current working directory (it is possible for Restrainer to have relative paths in the XML files be relative to the directory containing that XML though, I suppose).
Indeed, that is what it should be (and is done in other similar files, eg the XCode xml config file). If they are, then we don't have a problem since the script can use the get_example_path to find the xml file and all the data files will be in the same dir as the xml file. The context for finding data files in the xml file is the xml file, not whatever directory the user happens to call things from.

>> The directory containing the examples isn't necessarily writable (say
>> once they are installed), so we have to be careful about any files they
>> write. I think it is reasonable to insist that the working directory is
>> writeable to produce output, but we could also have the samples write to
>> a tmp dir.
> You have to balance the confusion that will ensue if users can't find the example outputs against trying to write output into an unwriteable directory. Since the latter yields a pretty clear error message, it seems preferable to me.
Agreed. I don't like the writing to a temp dir, which is why I think being able to run examples from anywhere is a good thing.