Hello Bjoern, On Aug 21, 2013, at 1:27 PM, Bjoern Gruening <bjoern.gruening@gmail.com> wrote:
Hi Greg,
seems to work fine!
Hello Bjoern,
On Aug 21, 2013, at 2:51 AM, Bjoern Gruening <bjoern.gruening@gmail.com> wrote:
Hi Greg,
a first test seems to work as expected for me, will test again with the whole CTB.
Great - thanks!
If I understood your commit you are searching now for the next valid 'installable' revision, aka a revision with metadata.
Yes, this is correct.
Just a thought ... is it really the next or the top (valid)?
In the case of repositories of type tool_dependency_definition, if the repository is associated with an installable revision, it will always be the tip. So in these cases, next will be tip or None, in which case an error has been encountered and should be handled as usual.
Does it make sense to have revisions for "Tool dependency definition". Only one valid revision should be possible, per definition or? So we could skip that revision the system entirely for "Tool dependency definition", or?
No, this is not a good approach. It is important to check for a valid ( i.e., installable ) changeset revision for all repositories, even those of type tool_dependency_definition. If a tool_dependency_definition repository does not have a tip that is installable, it should be handled just like other repositores that do not have an installable revision. In addition to the error handling that will result from checking for validity, the framework supporting repository revisions is less fragile and easier to maintain if exceptions like this for repository types are not introduced.
Ah ok, yes that makes sense. Also if it is not installable, it probably should not be possible to upload it, or?
It has always been possible to upload changeset revisions with invalid contents. The tool shed will simply attempt to communicate the reason the contents are invalid. I'm not sure this case should be handled differently.
Thanks for the clarification. Bjoern
Thanks for the fast fix! Bjoern
Thanks!
Greg Von Kuster
Hello Bjoern,
This issue should be resolved in change set 10412:29ab5a6d75a7, whcih is currently running on both tool sheds. No changes should be necessary to any of your current dependency definition files.
This changeset was committed to the stable branch, so production Galaxy environments can be safely updated as well. Of course, tracking central in Galaxy environments will get the fix as usual.
Thanks very much for reporting this!
Greg Von Kuster
On Aug 15, 2013, at 9:01 AM, Bjoern Gruening <bjoern.gruening@gmail.com> wrote:
Hi Dave,
the bug is unfortunately still present in the latest Galaxy version.
If you try to install http://toolshed.g2.bx.psu.edu/view/iuc/package_scipy_0_12 you will end up with an error, because numpy is not found. That error appears because scipy was uploaded and afterwards numpy was changed. The consequence is that scipy references on old (not installable) version of numpy and crashes.
I would expect that scipy is always looking for the latest version of numpy regardless of what is specified in the numpy XML file. Is that assumption wrong? That would raise the question if revisions are still needed for orphan-tool-dependencies or 'Tool dependency definition'.
Is that bug easy to fix? Or do I need to upload all my repositories in the right order again? That would be the consequence, because otherwise I do not get the revision tag updated.
Thanks! Bjoern
Peter, Björn,
The August Galaxy release is out, and the template_command is now in the stable repository and branch. Regarding matplotlib and numpy, I currently only see matplotlib depending on the 74c21f9bdc39 revision of numpy. Is this still an issue, or has it been resolved?
--Dave B.
On 8/12/13 11:36:00.000, Bjoern Gruening wrote: > On Mon, 2013-08-12 at 16:32 +0100, Peter Cock wrote: >> On Mon, Aug 12, 2013 at 4:25 PM, Bjoern Gruening >> <bjoern.gruening@gmail.com> wrote: >>> On Mon, 2013-08-12 at 15:55 +0100, Peter Cock wrote: >>>> Maybe I should retitle this thread... >>>> >>>> On Mon, Aug 12, 2013 at 3:43 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote: >>>>> >>>>> Thank you - installing the NumPy package now works for me, >>>>> http://toolshed.g2.bx.psu.edu/view/iuc/package_numpy_1_7 >>>>> >>>>> I'm moving on to something odd with matplotlib instead... >>>>> >>>>> Peter >>>> >>>> There are currently two revisions to the main Tool Shed >>>> package for numpy, >>>> http://toolshed.g2.bx.psu.edu/view/iuc/package_numpy_1_7 >>>> >>>> Rev 0: c75482be1d3a - needs not-yet-released features >>>> Rev 1: 74c21f9bdc39 - simplified >>>> >>>> I'm trying to install a package dependent on this via >>>> matplotlib - but installing the matplotlib package fails: >>>> http://toolshed.g2.bx.psu.edu/view/iuc/package_matplotlib_1_2 >>>> >>>> This is something odd, why does it think it needs to install >>>> the rev 0 c75482be1d3a version of package_numpy_1_7? >>>> See screenshot, except here: >>>> >>>> Repository dependencies - installation of these additional >>>> repositories is required >>>> Name Revision Owner Installation status >>>> package_freetype_2_4 8761091302c4 iuc Installed >>>> package_numpy_1_7 74c21f9bdc39 iuc Installed >>>> package_numpy_1_7 c75482be1d3a iuc Uninstalled >>>> >>>> Yes, the matplotlib tool_dependencies.xml does list the >>>> original revision: >>>> >>>> <package name="numpy" version="1.7.1"> >>>> <repository changeset_revision="c75482be1d3a" >>>> name="package_numpy_1_7" owner="iuc" >>>> prior_installation_required="True" >>>> toolshed="http://toolshed.g2.bx.psu.edu" /> >>>> </package> >>>> <package name="freetype" version="2.4.11"> >>>> <repository changeset_revision="8761091302c4" >>>> name="package_freetype_2_4" owner="iuc" >>>> prior_installation_required="True" >>>> toolshed="http://toolshed.g2.bx.psu.edu" /> >>>> </package> >>>> >>>> But I thought as a "Tool dependency definition" only the >>>> tip revision is ever used? >>> >>> That is also what I understood, regardless of the revision there is only >>> one install able revision. But I guess the TS is generating the path to >>> numpy from the <package> tag and that points to an old non existing >>> version. >> >> Hmm. Something for Greg to look at then. >> >>>> After attempting to install this, the status is "Installed, missing >>>> repository dependencies" and this oddity about wanting two >>>> revisions of NumPy persists. >>>> >>>> The actual failure appears to be in compiling matplotlib itself... >>>> I don't think it is finding the NumPy installation. >>>> >>>> Is it possible to view the INSTALLATION.log from within the >>>> Galaxy Admin web interface? >>> >>> Yes you should see all installed files/folder and the INSTALLATION.log >>> in your web browser. >> >> Can you give me a little more information on how to see >> this from within Galaxy? >> >> 1. Open my Galaxy instance and log in, >> 2. Click on "Admin" from top menu >> 3. Click on "Manage installed tool shed repositories" on left >> 4. Select repository of interest > > 5. Click, "Manage tool dependencies" > 6. Choose one of the dependencies > > There should be a tree like structure to navigate to your > INSTALLATION.log file besides your env.sh file. > >> At this point the repository drop down menus I see are >> "Get updates" and "Delete or inactivate". I must be looking >> in the wrong place? >> >>> >>> I can reproduce it here and it fails because of numpy. >> >> OK, that's good - it sounds like the rival revision problem >> is what is going wrong. >> >>> >>> One fix to get it working is to upload again biopython. >> >> Good plan - as discussed here: >> http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-August/016001.html > > Done. > >> Thank you, >> >> Peter > > > ___________________________________________________________ > 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: > http://lists.bx.psu.edu/ > > 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: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/