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:


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).



On Fri, Jun 20, 2014 at 5:15 AM, John Chilton <jmchil...@gmail.com> wrote:
> Bjoern,
> The following patch should put out the fire...
> https://bitbucket.org/galaxy/galaxy-central/commits/d781366bc120787e201b73a4dd99b56282169d86
> 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
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to