Hi,

I'm afraid it won't be easy to reproduce my problem with a clean galaxy install. I think it has to do with the history of the instance, a lot of back and forth on the tool installations and also lot's of failed installations (due to my environment or network issues).

Investigating the issue Marius mentioned also seems worthwhile to me, it sounds like it could be the underlying bug. What might also help is a way to really purge all traces of a tool or tool dependency (and all it's versions) from the disk and the database. Currently the only way to solve my numpy revision issue would be to delete the whole tool install database (which I learned to put in a different db and I already resorted to that once in the beginning). I had a look at the database and it looks messed up, but I don't know enough about it to feel comfortable changing entries. I'm happy to send a DB dump along, if this is helpful for anyone.

Best regards,
Sarah


----
Sarah Diehl
HPC System Administrator
 
UNIVERSITÉ DU LUXEMBOURG
 
LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
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.
-----


From: Marius van den Beek <m.vandenbeek@gmail.com>
Date: Tuesday 20 October 2015 09:53
To: Björn Grüning <bjoern.gruening@gmail.com>
Cc: Sarah DIEHL <sarah.diehl@uni.lu>, "galaxy-dev@lists.galaxyproject.org" <galaxy-dev@lists.galaxyproject.org>
Subject: Re: [galaxy-dev] recurring issues with revisions of packages from toolshed

Sorry to hijack the thread, but I think the issue that Sarah has described could be related to
https://github.com/galaxyproject/galaxy/issues/667.
(I know it's not exactly the same, but chances are we fix this, we automatically fix Sarah's issue.)
There is also an example to reproduce https://github.com/galaxyproject/galaxy/issues/667#issuecomment-138878174
And I made a bit of work on this in Pull Request: https://github.com/galaxyproject/galaxy/pull/707
But unfortunately at the time this was a bit over my head.
Bjoern, if you want to work on this, let me know, maybe I can give you a hand.

Hope that's helpful,
Marius

On 19 October 2015 at 23:17, Björn Grüning <bjoern.gruening@gmail.com> wrote:
Hi Sarah,

can you create a reproducible example in a Docker container for me?
Together with a friend I will have a look at this. But we need to short
reproducible example :)

Thanks,
Bjoern


> 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
>
> UNIVERSITÉ DU LUXEMBOURG
>
> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE Campus Belval | Biotech II
> 6, avenue du Swing L-4371 Belvaux T +352 46 66 44 5360
> sarah.diehl@uni.lu<mailto:sarah.diehl@uni.lu>
> http://lcsb.uni.lu<http://lcsb.uni.lu/> ----- 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: https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
> http://galaxyproject.org/search/mailinglists/
>
___________________________________________________________
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/