Re: [galaxy-dev] Cloudman and parameterized launching

[Brad Chapman]

Scott;
The user passes in the AWS access and secret keys in the user-data
box. This page has all the details about the YAML format CloudMan
expects (in step 2 of the detailed steps):

http://wiki.g2.bx.psu.edu/Admin/Cloud

You can pick the passed in user-data up from any instance with
this url:

http://169.254.169.254/latest/user-data

and parsing it. CloudMan uses a script (in Python) that runs at boot:

https://github.com/chapmanb/cloudbiolinux/blob/master/installed_files/ec2autorun.py#L35

with a little upstart script in /etc/init/cloudman.conf:

https://github.com/chapmanb/cloudbiolinux/blob/master/cloudbio/cloudman.py#L8

Once you've got it in your script you can parse and use it as you need.
Hope this helps,
Brad

> This is only sort of a Galaxy question, in the sense of "how did you guys
> do that so I can too" sort of way.  I'm trying to clean up some code
> written by an undergrad for the GBrowse2 cloud machine, where he used less
> than secure methods of doing things.  I gather from the page on Cloudman
> that it uses a parameterized launch, where the user provides both halves of
> his API key, so that the Cloudman master node can do things like provision
> storage and start other instances.  Since I need to be able to do
> essentially the same thing (but in perl!), I was wondering if you could
> direct me to the resources you used to implement that and point out any
> gotchas that you can think of.
> 
> Thanks much and keep up the good work!
> Scott
> 
> 
> -- 
> 
> Scott Cain, Ph. D.   scott at scottcain dot
> net
> GMOD Coordinator (http://gmod.org/) 216-392-3087
> Ontario Institute for Cancer Research
Non-text part: text/html
> ___
> 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/
___
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] Excel upload problems

[Peter Cock]

> On Fri, Dec 9, 2011 at 3:35 AM, Peter Cock  wrote:
>>
>> P.S. Why do you call your class XIs, surely Excel would be
>> clearer?

I've only just realised Xls is title case xls (as in the extension),
I read it at the title case of xis (which made no sense). I still
think using Excel as the class name would be clearer.

On Thu, Dec 8, 2011 at 9:01 PM, Ross  wrote:
> +1
> I'd agree that calling it excel is suitably wry - because it doesn't IMHO.
> Please name the new binary datatype something other than xls because
> many (of my) tools create outputs with that extension and it's a
> subclass of tabular here - the .xls extension fools excel into loading
> them automagically.

I don't entirely agree with your logic, but I would agree that
as the format name it would be consistent with most of the
other Galaxy formats to go for a longer name (e.g. "excel")
over a short 3 letter extension (here "xls").

However, does this matter for the extension that Galaxy
gives on downloading the dataset, or is that all done via
the mime type? We want it to be easy for people to
download an Excel file from Galaxy and open it, which
means getting the extension right under Windows.

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/

[galaxy-dev] January 2012 Galaxy Events: Dec 15 Deadline for Czech Republic Workshop

[Dave Clements]

Hello all,

The January Events  email is going out a
little early this month, mainly because of a *December 15 deadline for
the Galaxy
Developer Workshop in the Czech
Republic
*.

There are Galaxy-related events on (at least) 3 continents next month:

* Date *

* Topic/Event *

* Venue/Location *

* Contact *

January 8-21

*2012 Workshop on
Genomics
*
Features Galaxy and much more.

Český Krumlov, Czech Republic

James Taylor 

January 14-18

*Galaxy 
Session@
GMOD
Workshop
*, and
*The Galaxy Platform: Running Analyses in the
Cloud@
Cloud
Computing 
Session
*

PAG 2012 , San Diego, California,
United States

Dave Clements 
Dannon Baker

January 17

*Reproducible workflows for next generation sequencing
analysis
*

Nowgen , University of
Manchester,
United Kingdom

Tom Hancocks 

January 23

*Galaxy Developer
Workshop
Application deadline is December 15.*

Český Krumlov, Czech Republic , immediately
following the Workshop on
Genomics,
(which also features Galaxy content)

James Taylor 

January 26

*今回の講習会では，「Next-Generation Sequencer(NGS) 微生物解析と Galaxy
ツール」を中心に講義と実習を行ないます。講義内容をよりよく理解して 頂くために，PC
を使用した実習を行ないます。
*
(Next-Generation Sequencing (NGS) and microbiological analysis with Galaxy)

DNA Data Bank of Japan (DDBJ), National Institute of
Genetics

DDBJ 

And I apologize in advance if I messed up the translation of the event at
DDBJ !
Thanks,

Dave C.

-- 
http://galaxyproject.org/
http://getgalaxy.org/
http://usegalaxy.org/
http://galaxyproject.org/wiki/
___
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] Excel upload problems

[Ross]

+1
I'd agree that calling it excel is suitably wry - because it doesn't IMHO.
Please name the new binary datatype something other than xls because
many (of my) tools create outputs with that extension and it's a
subclass of tabular here - the .xls extension fools excel into loading
them automagically.


On Fri, Dec 9, 2011 at 3:35 AM, Peter Cock  wrote:
> On Thu, Dec 8, 2011 at 4:29 PM, Joe Cruz  wrote:
>> Hey Siemen,
>>
>> A workaround i'm currently using consists of creating an Xls
>> subclass of the Binary datatype class:
>
> That's not a workaround ;) - that's the correct approach,
> as per Greg's email.
>
> Not that I want to encourage people to use Excel files in
> Bioinformatics, but perhaps this should be applied to the
> main Galaxy repository - given at least two groups are using
> Excel files in Galaxy?
>
> Peter
>
> P.S. Why do you call your class XIs, surely Excel would be
> clearer?
> ___
> 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/



-- 
Ross Lazarus MBBS MPH;
Associate Professor, Harvard Medical School;
Head, Medical Bioinformatics, BakerIDI; Tel: +61 385321444;

___
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] Excel upload problems

[Peter Cock]

On Thu, Dec 8, 2011 at 4:29 PM, Joe Cruz  wrote:
> Hey Siemen,
>
> A workaround i'm currently using consists of creating an Xls
> subclass of the Binary datatype class:

That's not a workaround ;) - that's the correct approach,
as per Greg's email.

Not that I want to encourage people to use Excel files in
Bioinformatics, but perhaps this should be applied to the
main Galaxy repository - given at least two groups are using
Excel files in Galaxy?

Peter

P.S. Why do you call your class XIs, surely Excel would be
clearer?
___
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] Excel upload problems

[Joe Cruz]

Hey Siemen,

A workaround i'm currently using consists of creating an Xls subclass of
the Binary datatype class:

In *galaxy-dist/lib/galaxy/datatypes/binary.py* add xls to *
unsniffable_binary_formats* like this:

*unsniffable_binary_formats = [ 'ab1', 'scf' , 'xls' ]*

Also add the following class at the very end of the binary.py file:

*class Xls(Binary):*
*'''Class describing an Excel (xls) file'''*
*
*
*file_ext = 'xls'*

Then in your 'datatypes_conf.xml' add the following line (don't forget to
comment out or remove other xls datatype lines):

**

Then restart galaxy and when you upload an excel file you must explicitly
select 'xls' for the 'File Format' (I personally don't know how to get
'Auto-detect' to work for added datatypes such as xls).

If you have any questions about this implementation let me know.  Good luck.

Joe Cruz


On Thu, Dec 8, 2011 at 3:11 AM, Siemen Sikkema wrote:

> Hello!
>
> For our future galaxy users in Netherlands Bioinformatics Centre we'd like
> to support Excel uploads. We have our own excel to tabular CLI tool and I
> have been trying to get it working with galaxy. The tool itself is not the
> problem, but getting excel files uploaded is…
>
> We're running a local instance (hg identify: 949e4f5fa03a+ tip) on Mac for
> development purposes.
>
> The issues with excel are two-fold: XLSX files get unzipped automatically
> and a useless XML file remains, while uploading an XLS file results in:
> "The uploaded binary file contains inappropriate content". I've tried adding
>
>  display_in_upload="true"/>
>  display_in_upload="true"/>
>
> to datatypes_conf.xml and selecting XLS and XLSX as datatype during upload
> but to no avail (the errors don't change).
>
> A temporary workaround we thought of was to first zip the files before
> uploading, that way Galaxy would unzip them and we'd be left with the raw
> excel files. At first this seemed to work but the conversion did not.
> Furthermore, downloading the files and trying to open them failed. A quick
> 'diff' between the original and mangled files show differences practically
> throughout the whole file!
>
> Now, my questions are as follows. Has work been underway to support excel
> natively? Is there a way to have Galaxy simply accept uploaded files
> without any interpretation? What happens inside Galaxy that corrupts the
> excel files during unpacking?
>
> Thank you very much and I apologize if I somehow missed something obvious
> or if these questions have been asked before.
>
> Kind regards,
> Siemen Sikkema
> ___
> 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/
>
___
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] Excel upload problems

[Greg Von Kuster]

Hello Siemen,

You'll have to treat Excel files as a specific data type, and add support for 
that data type to Galaxy - see our wiki at 
http://wiki.g2.bx.psu.edu/Admin/Datatypes for details on how to add support for 
a new data type.  You can implement the Excel class in such a way that nothing 
gets munged, which is undoubtedly what is now happening when you upload the 
file because Galaxy sniffs it as some other data type.  

I'm not sure, but perhaps others in the community have done work in this area.

Greg Von Kuster

On Dec 8, 2011, at 4:11 AM, Siemen Sikkema wrote:

> Hello!
> 
> For our future galaxy users in Netherlands Bioinformatics Centre we'd like to 
> support Excel uploads. We have our own excel to tabular CLI tool and I have 
> been trying to get it working with galaxy. The tool itself is not the 
> problem, but getting excel files uploaded is…
> 
> We're running a local instance (hg identify: 949e4f5fa03a+ tip) on Mac for 
> development purposes.
> 
> The issues with excel are two-fold: XLSX files get unzipped automatically and 
> a useless XML file remains, while uploading an XLS file results in: "The 
> uploaded binary file contains inappropriate content". I've tried adding
> 
>  display_in_upload="true"/>
>  display_in_upload="true"/>
> 
> to datatypes_conf.xml and selecting XLS and XLSX as datatype during upload 
> but to no avail (the errors don't change).
> 
> A temporary workaround we thought of was to first zip the files before 
> uploading, that way Galaxy would unzip them and we'd be left with the raw 
> excel files. At first this seemed to work but the conversion did not. 
> Furthermore, downloading the files and trying to open them failed. A quick 
> 'diff' between the original and mangled files show differences practically 
> throughout the whole file!
> 
> Now, my questions are as follows. Has work been underway to support excel 
> natively? Is there a way to have Galaxy simply accept uploaded files without 
> any interpretation? What happens inside Galaxy that corrupts the excel files 
> during unpacking?
> 
> Thank you very much and I apologize if I somehow missed something obvious or 
> if these questions have been asked before.
> 
> Kind regards,
> Siemen Sikkema
> ___
> 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/
> 

Greg Von Kuster
Galaxy Development Team
g...@bx.psu.edu




___
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] FTP GALAXY

[Nate Coraor]

On Dec 7, 2011, at 10:19 PM, James Boocock wrote:

> Hi
> 
> We have set up galaxy in a production environment and our galaxy users can 
> connect to the FTP and upload files. No worries.
> 
> The settings in the universe file seem correct and are.
> 
> ftp_upload_dir = /home/galaxy/galaxy-dist/database/ftp
> 
> 
> It creates the directory and uploads the file. But when the user signs into 
> galaxy they cannot view their file in the get data  -> from files on my 
> computer.

Hi James,

You also need to set ftp_upload_site, if you haven't done so.

--nate

> 
> Proftp config is listed below.
> 
> Cheers James Boocock
> 
> ServerName  "Public Galaxy FTP"
> ServerType  standalone
> DefaultServer   on
> Port21
> Umask   077
> SyslogFacility  DAEMON
> SyslogLevel debug
> MaxInstances30
> Usernobody
> Group   nogroup
> DisplayConnect  /etc/opt/local/proftpd_welcome.txt
> 
> # Passive port range for the firewall
> PassivePorts3 4
> 
> # Cause every FTP user to be "jailed" (chrooted) into their home directory
> 
> DefaultRoot ~
> 
> # Automatically create home directory if it doesn't exist
> CreateHome  on dirmode 1700
> 
> # Allow users to overwrite their files
> AllowOverwrite  on
> 
> # Allow users to resume interrupted uploads
> AllowStoreRestart   on
> 
> # Bar use of SITE CHMOD
> 
>  DenyAll
> 
> 
> # Bar use of RETR (download) since this is not a public file drop
> 
>DenyAll
> 
> # Do not authenticate against real (system) users
>AuthPAM off
> 
> # Set up mod_sql_password - Galaxy passwords are stored as hex-encoded SHA1
>SQLPasswordEngine   on
>SQLPasswordEncoding hex
> 
> # Set up mod_sql to authenticate against the Galaxy database
>SQLEngine   on
>SQLBackend  postgres
>SQLConnectInfo  galaxydb galaxyftp 1234
>SQLAuthTypesSHA1
>SQLAuthenticate users
> 
> # An empty directory in case chroot fails
>SQLDefaultHomedir   /var/opt/local/proftpd
> 
> # Define a custom query for lookup that returns a passwd-like entry.  UID and 
> GID should match your Galaxy user.
> # Do not authenticate against real (system) users
>AuthPAM off
> 
> # Set up mod_sql_password - Galaxy passwords are stored as hex-encoded SHA1
>SQLPasswordEngine   on
>SQLPasswordEncoding hex
> 
> # Set up mod_sql to authenticate against the Galaxy database
>SQLEngine   on
>SQLBackend  postgres
>SQLConnectInfo  galaxydb galaxyftp 1234
>SQLAuthTypesSHA1
>SQLAuthenticate users
> 
> # An empty directory in case chroot fails
>SQLDefaultHomedir   /var/opt/local/proftpd
> 
> # Define a custom query for lookup that returns a passwd-like entry.  UID and 
> GID should match your Galaxy user.
>SQLUserInfo custom:/LookupGalaxyUser
>SQLNamedQuery   LookupGalaxyUser SELECT 
> "email,password,'512','512','/home/galaxy/galaxy-dist/database/ftp/%U','/bin/bash'
>  FROM galaxy_user WHERE email='%U'"
> 
> 
> 
>SQLUserInfo custom:/LookupGalaxyUser
>SQLNamedQuery   LookupGalaxyUser SELECT 
> "email,password,'512','512','/home/galaxy/galaxy-dist/database/ftp/%U','/bin/bash'
>  FROM galaxy_user WHERE email='%U'"
> 
> 
> 
> 
> ___
> 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/


___
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] Send data to Galaxy from external websites.

[Vishal R Patel]

Hi,

I searched the docs and mailing list but could not figure out how to export
data from my website directly to the *Main* public galaxy.

My webserver creates a bed file and has meta information like build, genome
etc. I would like to provide users with a button that allows them to
directly send data to the public instance of galaxy for further analysis.
I read about the synchronous method that Galaxy provides. But to me it
looked like the user has to navigate to the webpage from within Galaxy.
What I am looking for is some method which allows me to build a url of the
form

http://main.g2.bx.psu.edu/?import_data=URL_FOR_DATA&genome=GENOME&build=BUILD&format=FORMAT

or something like that! So galaxy can grab the data from the URL_FOR_DATA
and import it directly to the users current workspace. Is this possible?

Thanks,
Vishal
___
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] FTP GALAXY

[James Boocock]

Hi

We have set up galaxy in a production environment and our galaxy users 
can connect to the FTP and upload files. No worries.


The settings in the universe file seem correct and are.

ftp_upload_dir = /home/galaxy/galaxy-dist/database/ftp


It creates the directory and uploads the file. But when the user signs 
into galaxy they cannot view their file in the get data  -> from files 
on my computer.


Proftp config is listed below.

Cheers James Boocock

ServerName  "Public Galaxy FTP"
ServerType  standalone
DefaultServer   on
Port21
Umask   077
SyslogFacility  DAEMON
SyslogLevel debug
MaxInstances30
Usernobody
Group   nogroup
DisplayConnect  /etc/opt/local/proftpd_welcome.txt

# Passive port range for the firewall
PassivePorts3 4

# Cause every FTP user to be "jailed" (chrooted) into their home directory

DefaultRoot ~

# Automatically create home directory if it doesn't exist
CreateHome  on dirmode 1700

# Allow users to overwrite their files
AllowOverwrite  on

# Allow users to resume interrupted uploads
AllowStoreRestart   on

# Bar use of SITE CHMOD

  DenyAll


# Bar use of RETR (download) since this is not a public file drop

DenyAll

# Do not authenticate against real (system) users
AuthPAM off

# Set up mod_sql_password - Galaxy passwords are stored as hex-encoded SHA1
SQLPasswordEngine   on
SQLPasswordEncoding hex

# Set up mod_sql to authenticate against the Galaxy database
SQLEngine   on
SQLBackend  postgres
SQLConnectInfo  galaxydb galaxyftp 1234
SQLAuthTypesSHA1
SQLAuthenticate users

# An empty directory in case chroot fails
SQLDefaultHomedir   /var/opt/local/proftpd

# Define a custom query for lookup that returns a passwd-like entry.  
UID and GID should match your Galaxy user.

# Do not authenticate against real (system) users
AuthPAM off

# Set up mod_sql_password - Galaxy passwords are stored as hex-encoded SHA1
SQLPasswordEngine   on
SQLPasswordEncoding hex

# Set up mod_sql to authenticate against the Galaxy database
SQLEngine   on
SQLBackend  postgres
SQLConnectInfo  galaxydb galaxyftp 1234
SQLAuthTypesSHA1
SQLAuthenticate users

# An empty directory in case chroot fails
SQLDefaultHomedir   /var/opt/local/proftpd

# Define a custom query for lookup that returns a passwd-like entry.  
UID and GID should match your Galaxy user.

SQLUserInfo custom:/LookupGalaxyUser
SQLNamedQuery   LookupGalaxyUser SELECT 
"email,password,'512','512','/home/galaxy/galaxy-dist/database/ftp/%U','/bin/bash' 
FROM galaxy_user WHERE email='%U'"




SQLUserInfo custom:/LookupGalaxyUser
SQLNamedQuery   LookupGalaxyUser SELECT 
"email,password,'512','512','/home/galaxy/galaxy-dist/database/ftp/%U','/bin/bash' 
FROM galaxy_user WHERE email='%U'"





___
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] Cloudman and parameterized launching

[Scott Cain]

Hi Guys,

This is only sort of a Galaxy question, in the sense of "how did you guys
do that so I can too" sort of way.  I'm trying to clean up some code
written by an undergrad for the GBrowse2 cloud machine, where he used less
than secure methods of doing things.  I gather from the page on Cloudman
that it uses a parameterized launch, where the user provides both halves of
his API key, so that the Cloudman master node can do things like provision
storage and start other instances.  Since I need to be able to do
essentially the same thing (but in perl!), I was wondering if you could
direct me to the resources you used to implement that and point out any
gotchas that you can think of.

Thanks much and keep up the good work!
Scott


-- 

Scott Cain, Ph. D.   scott at scottcain dot
net
GMOD Coordinator (http://gmod.org/) 216-392-3087
Ontario Institute for Cancer Research
___
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] Excel upload problems

[Siemen Sikkema]

Hello!

For our future galaxy users in Netherlands Bioinformatics Centre we'd like to 
support Excel uploads. We have our own excel to tabular CLI tool and I have 
been trying to get it working with galaxy. The tool itself is not the problem, 
but getting excel files uploaded is…

We're running a local instance (hg identify: 949e4f5fa03a+ tip) on Mac for 
development purposes.

The issues with excel are two-fold: XLSX files get unzipped automatically and a 
useless XML file remains, while uploading an XLS file results in: "The uploaded 
binary file contains inappropriate content". I've tried adding




to datatypes_conf.xml and selecting XLS and XLSX as datatype during upload but 
to no avail (the errors don't change).

A temporary workaround we thought of was to first zip the files before 
uploading, that way Galaxy would unzip them and we'd be left with the raw excel 
files. At first this seemed to work but the conversion did not. Furthermore, 
downloading the files and trying to open them failed. A quick 'diff' between 
the original and mangled files show differences practically throughout the 
whole file!

Now, my questions are as follows. Has work been underway to support excel 
natively? Is there a way to have Galaxy simply accept uploaded files without 
any interpretation? What happens inside Galaxy that corrupts the excel files 
during unpacking?

Thank you very much and I apologize if I somehow missed something obvious or if 
these questions have been asked before.

Kind regards,
Siemen Sikkema
___
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] Configuring Toolsheds

[Greg Von Kuster]

Hi Zachary,

On Dec 8, 2011, at 10:11 AM, Zachary Charlop-Powers wrote:

> Greg,
> 
> I thought I sent the e-mail below last night. Sorry.  I reinstalled Galaxy 
> and ran into the same issue. Since I can modify my own tools and the 
> Toolsheds are not strictly necessary for what we are doing I am going to stop 
> trying for a bit.  I am a little confused that it doesn't work, however, and 
> wonder if there is not an issue in one of the scripts. I don't know which 
> script would be responsible for making a local copy of the Galaxy Toolshed 
> tools but when I  "grep" for "repository" in the /galaxy-dist/ folder the 
> only non-template file you get is 
> lib/galaxy/webapps/community/controllers/repository.py  I glanced through 
> that file but I didn't see a part of the script that had the exact order of 
> the error message I was receiving - but perhaps I didn't know the file very 
> well?


It seems you have a bit of a misunderstanding about the main Galaxy tool shed 
(http://toolshed.g2.bx.psu.edu/), and the mercurial repositories that are 
available in it as well as the motivation for hosting your own local Galaxy 
tool shed.  The mercurial repositories that are currently available in the main 
Galaxy tool shed can be "hg cloned" individually or "automatically installed" 
individually as a means of making their contents (Galaxy tools, workflows, 
data, etc) available to your local Galaxy instance.  So if you configure and 
host your own local Galaxy tool shed, your shed will not initially contain 
anything until you add your own locally developed tools to it.  Starting up a 
local tool shed does not result in the mercurial repositories currently 
available in the main galaxy tool shed being automatically made available in 
the local tool shed.

The intent of the main Galaxy tool shed is to enable sharing of tools between 
the many local Galaxy instances around the globe.  But again, the mercurial 
repositories containing these tools must be individually installed into your 
local Galaxy instance.  There are many way to go about doing this - all 
documented in the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed.  
This provides flexibility to those hosting their own local Galaxy instances in 
that they can install only those tools in which they have interest, and are not 
forced to get all of them in order to get any one of them.

In the near future, we will begin to move the tools currently included in the 
Galaxy distribution to the Galaxy main tool shed.


> 
> In any event I agree with you that it is not a server error nor a 
> community_wsgi.ini error (since I didn't do anything to them in this new 
> install) but something small in the setup where the repository is not being 
> told the correct location to install its tools.  If you have any suggestions 
> I am happy to try some small things but I have to give up for a bit because 
> its amazing how much time you can spend tracking these things down.

I would strongly suggest that you eliminate the use of proxying Galaxy behind 
apache as your proxy configuration is certainly the cause of the issues you are 
seeing.

> 
> 
> thanks again for your time and your efforts to the creation of this great 
> tool.
> zach cp
> 
> 
> 
> 
> 
> 
> Greg,
> 
> I've been looking very carefully at 
> http://wiki.g2.bx.psu.edu/Tool%20Shed#Automatic_installation_of_Galaxy_tool_shed_repository_tools_into_a_local_Galaxy_instance
>  to make sure that I have been doing this right. 
> 
> After encountering the initial error (directory not found) I : 
> 
>   1. prematurely attempted to setup a local Galaxy toolshed.
>   2. started to get a new series of issues related to community_wsgi.ini 
> and nginx.conf.
> 
> Clearly this was incorrect and I can restore the default configuration of 
> these files.  However the initial error which is that default Galaxy 
> installation procedure did not allow me to use the main Galaxy Toolshed Tools 
> remains.  According to the webpage above this should be a very simple 
> procedure, akin to the main Galaxy setup. 
> 
> 
> I think the best thing to do is to do a totally clean install, use the Apache 
> config files you guys have included for port forwarding and not mess with any 
> other files. If that is the case I should be able to install Galaxy Tools via 
> the web without starting up a second server.  I think thats probably the best 
> way to proceed - not too hard since I don;t really have any data or history 
> on the server yet. 
> 
> Just clean out the galaxy user home folder, create a new Postgresql database 
> and configure Apache. If I still have problems after that I will let you know.
> 
> thanks Greg,
> zach cp
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Dec 7, 2011, at 12:18 PM, Greg Von Kuster wrote:
> 
>> Based on the following requests from the bottom of your paster log, you are 
>> attempting to access the Galaxy main tool shed, not a locally running tool 
>> shed.  SInce this is the case, you do not need t

Re: [galaxy-dev] Workflow API (runtime modification of tool parameters)

[Dannon Baker]

Richard,

We do have a very high level doc on the wiki describing the galaxy architecture 
in general, and api-specific documentation is under construction.

http://wiki.g2.bx.psu.edu/Admin/Internals/Implementation%20Info
http://wiki.g2.bx.psu.edu/Admin/API

Specific to what you want to do with the API involving workflows, I would look 
at the two places from my previous email to see the current implementations of 
workflow running in both the standard interface and via the API.

Thanks, and let me know if I can help!

Dannon

On Dec 7, 2011, at 4:49 PM, Richard Park wrote:

> Hi Dannon,
> Thanks for the pointers. I am new to developing to galaxy and any help
> or guidance would be much appreciated. Are there any docs to help me
> understand how to code/debug galaxy? And if you have any suggestions
> for the general process of extending the API i would be very grateful.
> thanks,
> Richard

___
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] Toolshed fasta-section down?

[Bossers, Alex]

Hi
The fasta-manipulation section on toolshed seems to be down 
(http://toolshed.g2.bx.psu.edu/). Am I the only one experiencing this?
IE just returns me a blank error page not found. FF returns me another 
unhelpful error:
Server Error
An error occurred. See the error logs for more information. (Turn debug 
on to display exception reports here)

Alex



___
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] bwa setting metadata

[SHAUN WEBB]

Hi, I am running bwa using reference sacCer2. I have locally installed  
data for sacCer2 and the following line in builds.txt:


sacCer2 S. cerevisiae June 2008 (sacCer2)

This seems to work fine for other tools (e.g extracting genomic sequence).

When I run bwa the job runs correctly but the database field is not  
set properly. I get the following instead:


Project-Id-Version: PACKAGE VERSION Report-Msgid-Bugs-To:  
POT-Creation-Date: 2008-09-21 18:33+0900 PO-Revision-Date: 2009-03-17  
03:55-0400 Last-Translator: FULL NAME Language-Team: en Plural-Forms:  
nplurals=2; plural=(n != 1) MIME-Version: 1.0 Content-Type:  
text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit  
Generated-By: Babel 0.9.4



Any ideas where this is coming from?


Thanks
Shaun Webb

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


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