On 21.01.2015 16:11, John Chilton wrote:
So the tool dependency stuff didn't change - but the local job runner
now behaves like the other job runners (DRMAA, PBS, etc...) so you
have uncovered a bug for all of them I think. Is this a tool shed tool
or a locally created dependency?
This is a tool shed tool (package_mimodd_0_1_5), but one I uploaded
myself (I discovered the bug when I did a test install after updating
our local Galaxy).
I need to think about how to solve this more generally but if you want
a quick work around - I think it would work to just replace "python"
in $GALAXY_ROOT/set_metadata.sh with a hard-coded path to Galaxy's
python or perhaps just "python2".
Since I can change the tool shed tool a more "global" solution could be
to simply remove the "python" symlink from the python3 virtualenv after
its created and have the tool use "python3" explicitly at runtime. I'll
try whether that works, but I think it should.
Sorry for the inconvenience and thanks for bringing this to our attention.
No problem. I'm glad if I could help with something instead of just
asking questions all the time.
On Tue, Jan 20, 2015 at 12:52 PM, John Chilton <jmchil...@gmail.com> wrote:
Are you using the local job runner (this will be the case if you
haven't explicitly configured something like pbs or DRMAA in your
On Tue, Jan 20, 2015 at 12:34 PM, Wolfgang Maier
On 01/20/2015 06:20 PM, Wolfgang Maier wrote:
I have not seen this error before (I believe not with latest_2014.10.06)
update: confirmed this now. It's enough to hg update to latest_2014.10.06
and things are working again.
The difference is that when building the dependency shell command the latest
release seems to put the call to set_metadata.sh into that command, while
before it seems it was run separately.
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: