November 2011 - galaxy-dev - lists.galaxyproject.org

managing a soap session via galaxy
by James Ireland 25 Nov '11

25 Nov '11

Hi Galaxy developers, I'd like to integrate a SOAP-based data resource in Galaxy and I'm exploring ways to manage the SOAP session so that a user won't have to resubmit their credentials every time they want to pull data. Here are things I've thought of: 1) Wrap an independent web page around the SOAP service and access it via HTTP using Galaxy's synchronous data depositing. I could manage session cookies through my site rather than trying to do it with Galaxy. I'd like to avoid adding an extra layer, however, so then I thought of... 2) Can I set and read cookie attributes from a Galaxy Tool? If so, I think I could make this work but I don't see how I can access cookie attributes after reading the docs. I might be able to do it with some javascript magic, but I also don't see a way to add arbitrary bits of javascript to a tool page. 3) I might be able to keep a local table of SOAP credentials tied to the Galaxy Session Id. However, I'm not sure how/if I can pass the Galaxy session id to my custom tool? Any help or pointers would be greatly appreciated! Thanks, -James -- J Ireland www.5amsolutions.com | Software for Life(TM) m: 415 484-DATA (3282)

1 0

postgresql migration
by Jan Haas 25 Nov '11

25 Nov '11

Hi, I had a local instance running with the basic SQlite database setup running. Now I've changed to postgresql and all my users and histories aren't available. Is there a way of migrating the old data to the new database ? Best, Jan ___________________________________________________ Dipl. Biol. Jan Haas Otto Meyerhof Zentrum/Innere Medizin III Ruprecht-Karls-Universität Heidelberg Im Neuenheimer Feld 350 69120 Heidelberg Germany Tel. (office): +496221 56-38847 Tel. (lab): +496221 56-4835 email: jan.haas(a)med.uni-heidelberg.de

2 1

Galaxy Upload tool
by Toqa Manasrah 24 Nov '11

24 Nov '11

Hi everybody, I am integrating my own tool with galaxy. the command to run is: ./main.bash <readFile> <referenceFile> threads n t > <log> & the input files read and reference are of type fasta. threads, t and n are integers. log is to prevent console outputs. should I load these files from the page which run the command. or i have to use the Galaxy upload tool. and how? on the other hand. the output is implied and should be on the same directory where the source files. Thank you so much. Tuqa.

1 0

Read files
by Usha Reddy 23 Nov '11

23 Nov '11

Did anyone import raw read data from Complete Genomics into Galaxy? Also can we validate the raw sequence using Galaxy tools? Thanks, Usha

1 0

workflow suggestions
by Belinda M. Giardine 23 Nov '11

23 Nov '11

Some questions/suggestions about workflows. How do you remove a workflow that was shared with you by others from the list? You can view workflows shared with you, but can't view your own workflows, why? The annotations show up nice in the view format and especially for older workflows it would be good to see the annotations you made easily. Also good to see them as others will before publishing the workflow. I know this can be done through edit and clicking on each step, but not a nice as the view. Belinda

1 0

Re: [galaxy-dev] Backup strategy
by Mattias de Hollander 23 Nov '11

23 Nov '11

Hi, I was thinking of an incremental backup script using Backupninja to backup the galaxy configuration files. Not sure though how long to keep backups of galaxy datasets. What are other people doing? Greetz, Mattias

1 0

External/custom display applications
by Lukasse, Pieter 23 Nov '11

23 Nov '11

Hi, Is there more documentation on the topic of "custom display applications"? I only found http://wiki.g2.bx.psu.edu/Admin/Tools/External%20Display%20Applications%20T… which has a few examples, but these are incomplete. For example, they use some variables like ${BASE_URL} and ${DATASET_HASH} but I cannot find extra information on these and if there are more variables which I could use. Basically I want to build a tool which also its own display application next to the normal textual output file. Thanks and regards, Pieter Lukasse Wageningen UR, Plant Research International Departments of Bioscience and Bioinformatics Wageningen Campus, Building 107, Droevendaalsesteeg 1, 6708 PB, Wageningen, the Netherlands +31-317480891; skype: pieter.lukasse.wur http://www.pri.wur.nl<http://www.pri.wur.nl/>

1 0

Re: [galaxy-dev] Newbie question for toolshed development
by Greg Von Kuster 23 Nov '11

23 Nov '11

Hello Aaron, On Nov 23, 2011, at 8:20 AM, Aaron Quinlan wrote: > Hi Greg, > > Thanks again for your help. One last question (famous last words). In the CADDSuite example, it appears that they are distributing compiled binaries in their Tool Shed repo. I am hesitant to do this, owing to the fact that my tools are in C and C++, so compilation is platform dependent. Yes, including binary dependencies in the repository is not an ideal approach. > As such, I am planning to just release XML wrappers for BEDTools and assume that the users have already installed the appropriate release on their system. Does this meet with your expectations for tools that require compilation? Yes, for now this is the best solution. In the future, the tool shed will include support for handling small fabric scripts that can be included in the tool shed repository for tools that have requirements like this. These fabric scripts will point to the location where the dependency source can be downloaded and compiled on the platform on which the local Galaxy instance resides. As part of the automatic Galaxy tool installation process from the tool shed to the local Galaxy instance, these dependencies will be automatically downloaded and compiled for tools installed from the tool shed. Until this automated process is functional, 3rd party dependencies must still be manually installed just like they are for all of the Galaxy tools (that have requirements) that come in the distribution. The tool wrappers themselves, however can currently be automatically installed from the tool shed to a local Galaxy instance. > Here is my current repo including just one tool: > > http://testtoolshed.g2.bx.psu.edu/repository/browse_repositories?sort=name&… This looks good, but a couple of comments: 1. There is no longer any use for suite_config.xml - it was used in the old version of the tool shed, but is no longer used. 2. Including tool_conf.xml is not necessary - nothing is done with it. 3. Support for data types used by your tools that are not included in the Galaxy distribution will be available soon, so if your tools use them, you can include code files that include classes that support them. More information about this will soon be available in the tool shed wiki, but let me know if you have questions about this. Your current tool doesn't fall into this category. 4. Make sure that your tool configs include the <requirements> tag sets if the tool has a dependency. This is the tag set that will enable the use of the future fabric scripts discussed above. See the section of our tool config syntax wiki for details: http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax#A.3Crequiremen… > > Thanks again, > Aaron > > > > On Nov 18, 2011, at 12:07 PM, Greg Von Kuster wrote: > >> Hello Aaron, >> >> On Nov 18, 2011, at 10:37 AM, Aaron Quinlan wrote: >> >>> Hi Greg, >>> >>> I am in the process of trying to develop a set of Galaxy wrappers for the tools in my bedtools suite. I have read the Toolshed wiki, but I am still struggling with some very basic questions that I hope you can help me with. >> >> Thanks for your plans to contribute your Galaxy tools to the tool shed - the Galaxy community will appreciate this! >> >>> >>> 1. How should a tarball repository be structured for the toolshed? For example, bedtools currently includes a Makefile plus a src/ directory and sub-directories for each tool. The compiled objects go to obj/ and the binaries to bin/. >> >> The subdirectory hierarchy is completely up to you as the developer - the tools shed really doesn't care what this looks like (although I've included some thoughts on this in the following list). The intent of the Galaxy tool shed to be a place for sharing tools that have been tested to be functionally correct when loaded into a Galaxy instance. This means that you have developed the tools (with Galaxy wrappers) in your own local Galaxy development environment (and proved that they work within Galaxy) before uploading them to a Galaxy tool shed. >> >> Keep in mind that your tools will ultimately be installed for use in other's local Galaxy instances, so here are some "rules of thumb" with regard to your tool shed repository that you create to contain your tools. >> >> 1. Keep your repository clean - do not upload items like .git or .svn subdirectories if you use these tools for development. Upload only those files that make the tools functionally correct within a Galaxy instance. >> >> 2. For simple tools that have no requirements ( see the <requirements> tag set in our Tool config syntax wiki at http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax ), your tarball can consist of a single directory that includes your tool files. Here's an example: >> >> Contents: >> digital_dge >> DGE.xml >> DGEtest.xls >> DGEtest1out.html >> rgDGE.py >> >> 3. For tools that require an index files (.loc.sample), you can add subdirectories if you want (again, not required - it's up to you). Here's an example: >> >> Contents: >> blast2go >> tool-data/ >> blast2go.loc.sample >> tools/ >> ncbi_blast_plus/ >> blast2go.py >> blast2go.txt >> blast2go.xml >> >> 4. For tools (like those you've described) that have 3rd party dependencies, you should place them in some directory within the hierarchy - what you've described is fine. >> >> >>> By reading the wiki I gather that I also need to add a new directory that contains an XML wrapper for each tool. Is that correct? Is there a specific name for said directory that is expected by the Toolshed? >> >> Yes, you should do this and make sure the tools are functional within your local galaxy instance before uploading them to the tool shed. >> >>> >>> 2. Do you have an example repository that has a similar structure to what is described in #1? This would be very helpful as a means to follow the lead of something that already works. >> >> You can browse the directory hierarchy of any of the repositories in the tool shed using the "Browse repository tip files" pop-up menu option. Here's a good example that may be similar to yours: >> >> Contents: >> caddsuite_linux_x86_64 >> CADDSuite-1.0.1/ >> AntitargetRescorer >> AutoModel >> BindingDBCleaner >> CADDSuite-description.txt >> CombiLibGenerator >> ConstraintsFinder >> Converter >> DBExporter >> DBImporter >> DockResultMerger >> EvenSplit >> FeatureSelector >> GalaxyConfigGenerator >> GridBuilder >> IMGDock >> InputPartitioner >> InputReader >> InteractionConstraintDefiner >> LigCheck >> Ligand3DGenerator >> LigandFileSplitter >> ModelCreator >> MolCombine >> MolDepict >> MolFilter >> MolPredictor >> PDBCutter >> PDBDownload >> PartialChargesCopy >> PocketDetector >> Predictor >> PropertyModifier >> PropertyPlotter >> ProteinCheck >> ProteinProtonator >> README >> RMSDCalculator >> ScoreAnalyzer >> SimilarityAnalyzer >> SimpleRescorer >> SpatialConstraintDefiner >> TaGRes >> TaGRes-train >> Validator >> VendorFinder >> WaterFinder >> bin/ >> changelog.txt >> data/ >> galaxyconfigs/ >> install.sh >> lib/ >> license.txt >> setPathes.sh >> suite_config.xml >>> >> >>> I apologize if answers to these questions are made abundantly clear somewhere yet I have somehow missed it. >>> >>> Best, >>> Aaron >>> >>> >>> ___________________________________________________________ >>> 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 >> greg(a)bx.psu.edu >> >> >> > Greg Von Kuster Galaxy Development Team greg(a)bx.psu.edu

1 0

microarray & NGS
by Ivan Merelli 22 Nov '11

22 Nov '11

Hi Galaxy Users, I'm interested in integrating microarray and NGS data. My problem concerns the uploading of an affybatch object in Galaxy (I have a local instance of galaxy, but exacly the same problem is present in http://main.g2.bx.psu.edu) After processing the upload, the only message in the green output data box of the history is something like: ##failed to find /galaxy/main_database/files/003/251/dataset_3251699_files/rexpression.pheno Can you help me in understanding what's wrong? In particular the data which I'm trying to upload are created with rexpression (incidentally, is it still supported or novel versions are attended?), because this package gives my some problems and I'm trying to upload manually some results (which seems ok on the disk) to see what is happening. Cheers, Ivan P.s. Maybe some other packages exists to deal with microarray data in Galaxy? e.g. retrieving data from GEO/ArrayExpress, normalizing them, show in a matrix differential expressed genes to join/confront them with novel NGS experiment... I know it's a lot of stuff..

3 7

ROD file for 'Unified Genotyper' only 'vcf'
by Carlos Borroto 21 Nov '11

21 Nov '11

Hi, I found that the ROD file for the 'Unified Genotyper' tool, can be only vcf format. However for 'Count Covariates' and 'Indel Realigner', it can be vcf o, gatk_dbsnp or bed. Is this a bug or there is a limitation on GATK? Thanks, Carlos

2 1