Thanks for investigating this. I changed the subject and sent to the galaxy dev 

I've had a number of tools quit working recently.   Particularly tools that 
inspect the extra_files_path when setting metadata, Defuse, Rsem, SnpEff.

I think there was a change in the galaxy framework:
The extra_files_path when referenced from an input or output in the cheetah 
template sections of the tool config xml will be relative to the job working 
directly rather than the files location.
I've just changed a few of my tools on my server yesterday
from: <param_name>.extra_files_path
to:   <param_name>.dataset.extra_files_path
and they now work again.

Dan or John, is that the right way to handle this?


On 10/13/14, 9:29 PM, Andrew Lonie wrote:
Hi Jim. I am probably going about this the wrong way, but I am not
clear on how to report tool errors (if in fact this is a tool error!)

I've been trialling your snpeff wrapper from the test toolshed and
getting a consistent error with the SnpEff Download and SnpEff sub
tools (the SnpSift dbNSFP works fine). The problem seems to be with an
attribute declaration and manifests during database download as:

Traceback (most recent call last):
   File "/mnt/galaxy/galaxy-app/lib/galaxy/jobs/runners/",
line 564, in finish_job
     job_state.job_wrapper.finish( stdout, stderr, exit_code )
   File "/mnt/galaxy/galaxy-app/lib/galaxy/jobs/", line
1107, in finish
     dataset.datatype.set_meta( dataset, overwrite=False )  # call
datatype.set_meta directly for the initial set_meta call during
dataset creation
line 21, in set_meta
     data_dir = dataset.files_path
AttributeError: 'HistoryDatasetAssociation' object has no attribute 'files_path'

We fiddled around with the wrapper, eventually replacing
'dataset.files_path' with 'dataset.extra_files_path' in,
which fixed the download bug, but then SnpEff subtool itself threw a
similar error when I tried to use that database from the history.

I chased up a bit more but cannot understand the various posts on
files_path vs extra_files_path

I've shared a history with both of these errors here:

Maybe this is a problem with our Galaxy image?

Any help appreciated!


A/Prof Andrew Lonie
University of Melbourne

James E. Johnson Minnesota Supercomputing Institute University of Minnesota
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