Regarding package dependency.
Assume there packages A, B and C
B depends on A and C on A and B

At the Start there is
A0, B0 and C0
B0 depends on A0 and C0 on A0 and B0

Now if A is updated there is a A1
But B0 still depends on A0 and C0 still on A0 and B0

Now if C is updated you have C1
C1 detects the latest versions of A and B so depends on A1 and B0
But B0 still depends on A0

The result is that C1 directly depends on A1 and indirectly (via B0) on A0

Could the tool shed detect this double dependency and refuse to load C1 unless 
it specifically references A0 and B0

Regard R 
I agree that as a wrapper it Galaxy is highly dependent on what the underlying 
tools report.

And if they change what they report that is a disaster.

What I do in my testing is after all the R is loaded try to run an R script 
which loads the packages as a test.

Something like:
writeLines(capture.output(sessionInfo()), args[1])

But even then the tool goes green with an R error,


From: Björn Grüning []
Sent: Thursday, October 15, 2015 10:48 AM
To: Christian Brenninkmeijer; Sarah DIEHL;
Subject: Re: [galaxy-dev] recurring issues with revisions of packages from 

Am 15.10.2015 um 11:43 schrieb Christian Brenninkmeijer:
> Note these are personal views of another admin not official Galaxy views.
> The version issues is a hard one to solve, as automatically updating upstream 
> project is also dangerous as that leaves them in a state that has not be 
> verified by the developer.
> Best solution could be for the toolshed to warn if a tool upload would pull 
> in multiple versions.

Can you elaborate there a little bit more?

> As for the R install issue.
> 1. I too find it extremely frustrating how often Galaxy just silently fails.

We are working on this.

But it is really hard to convince R to provide us with a real error
code. I spend several days, but different R versions, fail differently
or not at all ..

I will keep you posted on this and hopefully the latest idea from us
works out.

Sorry for any inconvenience,

> 2. It could be due to a missing R package.
> The galaxy tool to determine required R packages appears to miss ones only 
> listed as linked in.
> For example I had one which depends on lme4.
> This failed to build because RcppEigen was missing
> Yet it RccpEigen is only listed as "LinkingTo:"
> Christian
> ________________________________
> From: galaxy-dev [] on behalf of 
> Sarah DIEHL []
> Sent: Wednesday, October 14, 2015 2:05 PM
> To:
> Subject: [galaxy-dev] recurring issues with revisions of packages from 
> toolshed
> Dear all,
> I continuously have several issues with tool dependency packages from the 
> toolshed and their revisions. It looks like the tools I install have 
> requirements for different revisions of the same package_xy repository. What 
> I end up with quite often is having the same package installed in multiple 
> revisions (see attached "galaxytools_multiple_revisions.jpg" screenshot). 
> When I then update the older revision, it's still listet twice and 
> additionally the tool that had the older one as a dependency now says it's 
> missing a repository dependency.
> Although this is already quite annoying and creates a mess within the tool 
> list, I could live with it. However, sometimes it completely messes up 
> revisions. In the second attached screenshot (numpy_revision_issue.jpg) you 
> can see that this numpy repository thinks it is revision "300877695495", but 
> it's actual location has revision "8b3a5c7061d8". This causes tools that 
> depend on revision "300877695495" to think it's there, but when the 
> dependency is resolved at runtime of the tool, numpy is not found (since it's 
> location is in a different revision's folder) and the run fails. As you can 
> also see from the screenshot, resetting the metadata doesn't do anything 
> about this. Also reinstalling doesn't work, since the database keeps the 
> faulty record and uses it upon reinstallation.
> I think it's a problem that when I install tools that have outdated revisions 
> of a package repository as a dependency, they don't recognize that a newer 
> version is available (and already installed), but instead insist on 
> installing the older revision, too. I don't understand why they even have 
> this strict requirement on a specific version of a package repo, and not just 
> the version of the tool inside.
> Btw. I also noticed that the installation of R packages (e.g. in 
> package_dexseq_1_14) silently fails. Some of the requirements and also the 
> dexseq R package itself failed the installation, but Galaxy didn't recognize 
> any error and it still showed up as "Installed".
> Best regards,
> Sarah
> ----
> Sarah Diehl
> HPC System Administrator
> Campus Belval | Biotech II
> 6, avenue du Swing
> L-4371 Belvaux
> T +352 46 66 44 5360
> -----
> This message is confidential and may contain privileged information. It is 
> intended for the named recipient only. If you receive it in error please 
> notify me and permanently delete the original message and any copies.
> -----
> ___________________________________________________________
> 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:
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