Re: [galaxy-dev] Where should I put a tool's required binaries?

2012-11-05 Thread Joel Rosenberg

Thanks, James. That page is exactly what I was looking for. 
  
___
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/


Re: [galaxy-dev] Where should I put a tool's required binaries?

2012-11-05 Thread Joel Rosenberg

Thanks Peter,

I tried doing something similar, but there wasn't a location in the galaxy 
user's $PATH that would persist across a cluster reboot or could be snapshotted 
(like the tools or data volumes). Adding /mnt/galaxyTools/my_dep_binaries or 
something to the $PATH would work temporarily, but not past a reboot as 
/home/galaxy/.bashrc, /etc/environment, etc are part of the AMI and would be 
lost.

In your cluster, wouldn't the galaxy user's ${HOME}/bin be transient? Are you 
running with a different EC2 setup or using a different AMI?

-Joel



> Date: Mon, 5 Nov 2012 17:44:49 +
> Subject: Re: [galaxy-dev] Where should I put a tool's required binaries?
> From: p.j.a.c...@googlemail.com
> To: thisisj...@hotmail.com
> CC: galaxy-dev@lists.bx.psu.edu
>
> On Mon, Nov 5, 2012 at 5:34 PM, Joel Rosenberg  wrote:
> >
> > Sorry for bumping this, but it seems like such a standard boilerplate
> > step of installing a tool that someone muts know how.
> >
> > -Joel
> >
>
> Personally I've just been installing them on the $PATH, typically
> under $HOME/bin of the Galaxy user which is on our Galaxy
> user account's $PATH.
>
> 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/


Re: [galaxy-dev] Where should I put a tool's required binaries?

2012-11-05 Thread Joel Rosenberg

Sorry for bumping this, but it seems like such a standard boilerplate step of 
installing a tool that someone muts know how.

-Joel

>
> I installed the?bedtools tool from the public toolshed to my galaxy cluster. 
> The jobs were failing because I hadn't installed the required binaries:
>
> ? ?An error occurred running this job: 
> /opt/sge/default/spool/execd/ip-10-194-50-118/job_scripts/2: line 13: 
> genomeCoverageBed: command not found
>
> Taking a closer look at the toolshed's page, I noticed there were a handful 
> of required binaries (genomeCoverageBed,?intersectBed, etc).
>
> So I downloaded BEDTools and compiled all the binaries. I've put them in well 
> organized directories using symlinks to specific versions, etc. The final 
> executable directory containing symlinks to these binaries is 
> "/mnt/galaxyTools/shed_tool_binaries/bin/".
>
> I can make a snapshot of the tools volume so that these compiled binaries are 
> always available to me when I bring up my cluster, but how do I integrate 
> them into the PATH in a way that lets the bedtools galaxy tool see them, but 
> also survive cluster shutdowns?
>
> Thanks,
>
> -Joel
>

  
___
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/


[galaxy-dev] Where should I put a tool's required binaries?

2012-11-01 Thread Joel Rosenberg

I installed the bedtools tool from the public toolshed to my galaxy cluster. 
The jobs were failing because I hadn't installed the required binaries:

   An error occurred running this job: 
/opt/sge/default/spool/execd/ip-10-194-50-118/job_scripts/2: line 13: 
genomeCoverageBed: command not found

Taking a closer look at the toolshed's page, I noticed there were a handful of 
required binaries (genomeCoverageBed, intersectBed, etc).

So I downloaded BEDTools and compiled all the binaries. I've put them in well 
organized directories using symlinks to specific versions, etc. The final 
executable directory containing symlinks to these binaries is 
"/mnt/galaxyTools/shed_tool_binaries/bin/".

I can make a snapshot of the tools volume so that these compiled binaries are 
always available to me when I bring up my cluster, but how do I integrate them 
into the PATH in a way that lets the bedtools galaxy tool see them, but also 
survive cluster shutdowns?

Thanks,

-Joel 
___
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/


Re: [galaxy-dev] Cannot install ncbi_blast_plus or other tools from Tool Shed: HTTP 500 error

2012-10-24 Thread Joel Rosenberg

The galaxy webserver can solve this by allowing cross-domain resources from 
whatever toolsheds have been configured.

http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

-Joel 
___
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/


[galaxy-dev] Question about long term goal of Tool Shed usage

2012-10-08 Thread Joel Rosenberg

Hello,

I've been learning about the tool shed, as precipitated by the decision to move 
the blast tool out of the standard distribution.

(I'm having a problem doing so as documented here: 
http://dev.list.galaxyproject.org/Cannot-install-ncbi-blast-plus-or-other-tools-from-Tool-Shed-HTTP-500-error-td4656553.html
 , but that's not the point of this email)

Is there a goal to move every tool that's currently included in the EC2 tools 
snapshot to the public tool shed to keep the standard galaxy distribution 
leaner? If so, I have two questions/concerns:

1) How will this work with the concept of a tool volume snapshot? I'd have to 
make a snapshot of my partition every time I installed/removed a tool from a 
tool shed. Would it make sense to re-characterize the tools volume as a 
persistent volume (a la the user data volume) instead of it being snapshot 
driven like it is now? Is it currently possible for me to point to a persistent 
EC2 tools volume and not a snapshot in my persistent S3 information in order to 
make the cluster stop/start process simpler?

2) Are there plans to provide ranking or popularity ratings to the public tool 
shed so I know which tools are the most stable, popular, or perhaps used to be 
included in the standard distribution?

Thanks again for your work, apologies for the verbosity, I'm just getting to 
know galaxy.

-Joel 
___
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/


[galaxy-dev] Cannot install ncbi_blast_plus or other tools from Tool Shed: HTTP 500 error

2012-10-08 Thread Joel Rosenberg

(Apologies if this is in duplicate, Peter Cock may have forwarded it on after I 
posted it to the user list)

So I'm trying to install the recently migrated ncbi_blast_plus tool from the 
Tool Shed to my local galaxy instance running in EC2 and am getting errors at 
the installation step. 

After clicking "Install to local Galaxy" I immediately get: "Server Error An 
error occurred. See the error logs for more information. (Turn debug on to 
display exception reports here)" and an HTTP 500 error code is returned. Chrome 
tells me the URL it's attempting to request is: 

http://toolshed.g2.bx.psu.edu/repository/install_repositories_by_revision?changeset_revisions=a4b9836f8f47&repository_ids=cd0d8ada19d98f27

I tried the same process for other non-blast related tools that appeared to be 
simple (no 3rd party binary dependencies) and got the same server error. 

I restarted galaxy with its log level set to DEBUG and wasn't illuminated 
further, but that doesn't surprise me since my browser's requesting data from 
the public toolshed, not my server. 

I just performed a mercurial update in my cluster, too. 

Any ideas?
___
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/