[galaxy-dev] Galaxy Tool Shed packages for Biopython

2013-09-13 Thread Peter Cock
Hi all, I've send this to both the Galaxy and Biopython developers lists, and hope this will make sense to both groups. If you've not heard of Galaxy, start here: http://galaxyproject.org - while the easy to guess Biopython website is at http://biopython.org Brad Chapman and I are both Biopython

Re: [galaxy-dev] Viewing old nightly test results on the (Test) Tool Shed

2013-09-13 Thread Peter Cock
On Thu, Sep 12, 2013 at 2:21 PM, Peter Cock p.j.a.c...@googlemail.com wrote: Hi all, I was wondering if the web interface for the Tool Shed could allow us to look back at old test results? This would be useful in connection with explicit revisions to the tool concerned, but also when

Re: [galaxy-dev] Galaxy Tool Shed packages for Biopython

2013-09-13 Thread Peter Cock
On Fri, Sep 13, 2013 at 9:54 AM, Peter Cock p.j.a.c...@googlemail.com wrote: Hi all, ... The Biopython packages, however, are under a dedicated biopython account on the Galaxy Tool Shed to which currently Bjoern, Brad and I have access to: http://toolshed.g2.bx.psu.edu/view/biopython/

[galaxy-dev] toolshed tool versions and tool panel

2013-09-13 Thread Lukasse, Pieter
Hi Greg, When updating the version number of a tool I noticed that, as expected, both the old version and the new version of the tool become available in the Galaxy environment. What I did not expect is that the new version resulted in a new entry in the menu bar (see screenshot):

[galaxy-dev] A proposed modules extension for toolshed wrappers

2013-09-13 Thread Guest, Simon
Another vote for the excellent modules system from us at AgResearch Galaxy's dependency injection works in a similar way, without requiring all the external dependencies. We don't need unload since we compose a unique environment for every tool execution. This is much cleaner that loading

Re: [galaxy-dev] problems with toolshed package update process

2013-09-13 Thread Greg Von Kuster
Hello Pieter, The version of mercurial you are using is likely older than version 2.2.3. See: http://wiki.galaxyproject.org/ToolShedRepositoryFeatures#Pushing_changes_to_a_repository_using_hg_from_the_command_line Can you check this? Greg Von Kuster On Sep 13, 2013, at 5:54 AM, Lukasse,

Re: [galaxy-dev] toolshed tool versions and tool panel

2013-09-13 Thread Dave Bouvier
Pieter, Thank you for this report, I have reproduced this behavior in my local Galaxy instance. I did however notice that the tool version drop-down is still available on the tool's page, but multiple entries in the left-hand tool panel is not intended behavior. I've created a Trello card to

Re: [galaxy-dev] Circumvent Show all button

2013-09-13 Thread Gromobir
Hello Jeremy, Thanks a lot. That was the right parameter. :-) Best regards, Gromobir There is currently no simple way to circumvent this behavior. If you want to modify the code, take a look at display_data() in data.py -- you'll want to bump up the max_peek_size (line 351 in -central) above

[galaxy-dev] Bug: Galaxy Tool Shed dependency communication via HTTP GET method

2013-09-13 Thread Richard Burhans
When installing Galaxy Tool Shed repositories into a local Galaxy instance, tool shed dependecies are exchanged as an encoded python dictionary via the HTTP GET method. If a tool shed repository contains enough dependencies, the length of this encoded dictionary can become extremely long. In my

Re: [galaxy-dev] A proposed modules extension for toolshed wrappers

2013-09-13 Thread Guest, Simon
Just been reading a bit more about the Galaxy packaging system. Here's a slight modification to what I was suggesting that might fit in a bit better. Apologies for not being more familiar with the existing system before proposing extensions. Recall that my goal is to support using a

[galaxy-dev] Geek question re HTTP POST and Galaxy

2013-09-13 Thread Ted Goldstein, Ph.D.
I've been knocking my head over this all afternoon and I was hoping to buy a vowel, use a lifeline, whatever. I'm trying to use the Ember JS framework (which is very nice) for some extensions. It relies heavily on a REST model using the same method with all of the HTTP forms including

Re: [galaxy-dev] A proposed modules extension for toolshed wrappers

2013-09-13 Thread James Taylor
I'd like to propose a slightly different approach. I don't like the idea of introducing a different type of requirement for this because it really isn't a different type of requirement. You are still requiring a package, you just want to use a different mechanism to provide it. So, instead, what