Hello all, This is resurrecting an old thread, but using $input.extra_files_path rather than $input.files_path explained an unfortunate regression in the BLAST+ wrappers reported earlier today: https://github.com/peterjc/galaxy_blast/issues/69 Thanks John for his detective work. Given $output.files_path is considered preferable over $output.extra_files_path it would be great to have the same alias available for input parameters for consistency (although as per John's old email below, this may be tricky). Regards, Peter On Fri, Jun 20, 2014 at 5:15 AM, John Chilton <jmchilton@gmail.com> wrote:
Bjoern,
The following patch should put out the fire...
https://bitbucket.org/galaxy/galaxy-central/commits/d781366bc120787e201b73a4...
TL;DR - After this patch $output.extra_files_path is the same thing as $output.files_path - which is to say not broken in a bunch of corner cases and slightly less efficient in the most vanilla Galaxy deployments.
$input.extra_files_path however is a bit tricky if the path doesn't exist (probably not the case with your deployment Bjoern) - for disk object stores it just returns the non-existent path - for the nested object store it throws an error and the tool won't run. I had a patch to synchronize the behavior (https://gist.github.com/jmchilton/d05bcf02874762cdb829) - but I cannot say for sure the current behavior isn't intentional (Dannon, Nate - want to weigh in on this?).
-John