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
On Thu, Sep 12, 2013 at 2:21 PM, Peter Cock 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 something changed which
>
On Fri, Sep 13, 2013 at 9:54 AM, Peter Cock 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/
> http://testtools
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):
[cid:image00
> > 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
> lo
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, Piet
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
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) abo
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
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 system-in
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
Actio
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
Folks,
After checking a little closer last night, I have one clarification.
The Tool Shed does use POSTs as well as GETs, but even when it's
POSTing, the encoded dictionaries (encoded_repo_info_dicts) are part
of the query string. The encoded_repo_info_dicts should probably
become part of the PO
13 matches
Mail list logo