- galaxy-dev - lists.galaxyproject.org

API?
by Davide Cittaro 06 Oct '10

06 Oct '10

Hi there, I've been reading the last devnewsbrief... I've probably missed something, but I see that API should be available... where can I find docs about? thanks d /* Davide Cittaro Cogentech - Consortium for Genomic Technologies via adamello, 16 20139 Milano Italy tel.: +39(02)574303007 e-mail: davide.cittaro(a)ifom-ieo-campus.it */

3 3

October 5, 2010 Galaxy Development News Brief
by Jennifer Jackson 05 Oct '10

05 Oct '10

----- October 5, 2010 Galaxy Development News Brief ----- http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_… Here are the highlights of what you will get if you perform the following upgrade: hg pull -u -r d681ef7538ed ----- What's New ----- - Enhanced Data Library Features 1. Add the ability to make any library item public (and it's contents, if any) * There are now options on library item pop-up menus to make a library dataset public, make all contents of a folder public, or make an entire data library public. These new menu items are displayed only if the current item (dataset) is not public or if the current item (data library, folder) contains items that are not public. * The following image shows a data library that contains a restricted dataset and a folder that contains a restricted dataset. Since the data library contains items that are not public (restricted), it's Library Actions menu includes a "Make public" option. Selecting this option will make all of the contents of the entire data library public. http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_… * Similarly, the folder popup menu includes a "Make public" option since it contains a restricted dataset. Selecting this option at the folder level will only make the contents of the particular folder public. http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_… * The popup menu associated with any restricted library dataset will also include a "Make public" option. Selecting this option will make only that particular dataset public. http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_… 2. Upload Option changes * Move the upload options (ie., file, directory, filesystem paths, import from history), which used to be in the data library upload form's title bar popup menu, into a select list on the upload form. * Selecting a different upload option now performs a refresh on the upload form so that any form contents entered before selecting the option are now retained. http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_… - Extended Workflow and related History/Dataset Features 1. You can now flag a workflow step as an output within the editor. * To do this, hover over any output, click the asterisk to flag/unflag an output. If a workflow has outputs flagged, only those particular results will show in the history and all other outputs will be hidden. If no outputs are flagged, everything is shown (same as previous behavior). Note that workflow output flagging overrides HideDatasetActions; if a HideDatasetAction exists on a dataset flagged as a workflow output, it is removed. * This feature makes it much easier to take an existing workflow, and hide all of the outputs except for a small number of desired results. * It is worth noting that non-output results are only hidden, not deleted, and that they can be viewed in the history at any time by going to "View Hidden Datasets" in the history panel. 2. More options for Exporting, Searching, and Annotating * Both workflows and histories can now be exported to files. Importing workflows and histories is coming soon. * Annotations preserved when importing histories and workflows. * Tool search is now available in workflow editor so that you can search for tools when creating workflows. * Improvements for annotating histories and workflows to make it easier to add annotations. 3. Workflow Tool Form changes * Output extensions are now properly separated by ', ' (including space) instead of just slammed together. * Width is calculated better, taking into account the length of input and output rows, with an upper bound of 250px, and lower bound of 150px. 4. Post Job Actions * Separated into immediate and delayed actions. Immediate actions run when the job is created, as opposed to when it is finished. * Set Datatype is now an immediate action. This has no impact on the execution of the job, but it allows following jobs to queue with the correct subsequent datatypes. * RenameDatasetAction also happens immediately, rather than waiting for a job to complete. This makes the history less confusing to watch, as things don't randomly change names. 5. Updated UI - screenshots * Hovering for the tooltip on the asterisk. http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_… * A larger segment of a workflow, showing two Group steps flagged as outputs, one intermediary join not flagged as an output, and then a final cut that is flagged. http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_… * And, for larger workflows, note that the overview in the editor panel colors outputs, so you can find them at a glance. http://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_… ----- Updated & Improved ----- - Application Programming Interface (API) * API now returns data template information associated with a library dataset. * Added library dataset file_path to API captured information. - Data Upload * Allow for bz2 compressed uploads. Datasets can now be gzipped, bzipped, or zipped (only one file per zip, however). - Data Libraries * Clicking on a folder name now expands the folder instead of displaying information/description. * Moved folder icon to be next to the folder name and text (removing extra whitespace). * Rephrase naming for available compression schemes. * When viewing library dataset information under the Admin interface, a field is now present that displays the real path to the file on disk. - Mutation Visualization Tool * Requirement to enter the default columns indicating reference base, position, and start of sample. * New interactive zoom option: image can be zoomed in or out using the mouse wheel. - Trackster Visualization Tool * Better drawing of features at the bottom of viewing window. * Added track name dropdown for setting overview preferences. * Improved packing when zoomed (done on a w_scale basis instead of rounding to levels). - Documentation & Screencasts * Added more screencasts and topics in sample tracking documentation http://main.g2.bx.psu.edu/u/rkchak/p/sts - Community * Community ratings for all published items plus ratings are visible in published items lists. - Reproducibility * Tool parameters captured fresh when rerunning a process within an imported or copied history. - Functional Test Framework * Significant improvements to the functional test framework, especially those tests related to Galaxy forms and data libraries. * Allow the defining of a cluster job runner when running functional tests. - General * Changes to grids to make sorting order clear and reduce clutter from tags and annotations. * Adjusted BWA, Bowtie, and PerM wrappers so they now use verified use-case parameters. * Modified the 'file_path' field type in 'sample_dataset' table to 'TEXT' to support large file paths exceeding 255 characters. * Make the grouping, join, sort, and and any tool which uses r_wrapper.sh compatible with non-bash shells like bourne and dash (the default under modern Debian systems). - Bug Fixes! * Corrected bug that was causing Page item selection grids to be initialized twice and hence causing grid paging to fail. * Corrected bug in full parameter setting specification for Lastz. * Corrected typos in Tool Executed template and in Compute Motifs Frequency tool information. * Corrected import errors that would cause indel_analysis to fail under Python 2.6. ---- Galaxy Project Team http://usegalaxy.org http://bitbucket.org/galaxy/galaxy-central This project is supported in part by NSF, NHGRI, and the Huck Institutes of the Life Sciences, and The Institute for CyberScience at Penn State.

1 0

megablast installation in Galaxy
by Eric Enns 05 Oct '10

05 Oct '10

Hi I am implementing a local installation of galaxy and am stuck on the megablast portion. I installed blast 2.2.24 which includes formatdb and megablast. The installation guide says to use BLAST+, but that does not have megablast or formatdb in it. The megablast installation I have does not output in the correct format. How do I install BLAST+ so that it will work in galaxy. -Eric

3 2

Setting default entry in select parameter
by Peter 05 Oct '10

05 Oct '10

Hi all, I'm trying to setup a select parameter where I want to pre-select an entry as the default (rather than just the first entry). To that end, I have set the value attribute as implied by the wiki documentation: http://bitbucket.org/galaxy/galaxy-central/wiki/ToolConfigSyntax e.g. <param name="matrix" type="select" value="BLOSUM62" label="Scoring matrix"> <option value="BLOSUM80">BLOSUM80</option> <option value="BLOSUM62">BLOSUM62 (default)</option> <option value="BLOSUM50">BLOSUM50</option> <option value="BLOSUM45">BLOSUM45</option> <option value="PAM250">PAM250</option> <option value="BLOSUM90">BLOSUM90</option> <option value="PAM30">PAM30</option> <option value="PAM70">PAM70</option> </param> This does not work - Galaxy (in Firefox at least) always defaults to the first entry as the default. This also happens if I set display="radio". Is this a bug, is setting a default for select parameters done in another way, or is this a missing feature? For now I have just put the default at the top, breaking the alphabetic order: <param name="matrix" type="select" label="Scoring matrix"> <option value="BLOSUM62">BLOSUM62 (default)</option> <option value="BLOSUM80">BLOSUM80</option> <option value="BLOSUM50">BLOSUM50</option> <option value="BLOSUM45">BLOSUM45</option> <option value="PAM250">PAM250</option> <option value="BLOSUM90">BLOSUM90</option> <option value="PAM30">PAM30</option> <option value="PAM70">PAM70</option> </param> Regards, Peter

2 2

Managing galaxy-central in a local svn repo
by Branden Timm 05 Oct '10

05 Oct '10

Hello, I am trying to figure out the best way to use subversion to track both galaxy-central and our local tool integration work. We are standardized on subversion, so I'd like to use it if possible. What I've done so far: Downloaded the latest galaxy-central 'hg clone https://bitbucket.org/galaxy/galaxy-central' Copied galaxy-central, including mercurial info, into the /trunk subdirectory of my repo. My plan is that when future revisions to galaxy-central are available, I can create a new branch, use hg pull to update the codebase, test, and finally merge that branch back into /trunk. I noticed that just the size of the galaxy-central mercurial repo is about 230M. Is this because back-versions are being included? If so, should I just do a clone to the most recent revision and then use 'hg pull' to apply future revisions? Cheers -- Branden Timm University of Wisconsin Great Lakes Bioenergy Research Center btimm(a)glbrc.wisc.edu

2 1

Implementation of data connection protocol
by Zhe Chen 05 Oct '10

05 Oct '10

Hi, Can u tell me how to implement the "send query to galaxy" button on page http://genome.ucsc.edu/cgi-bin/hgTables ? which is the tool in (Get Data)->(UCSC Main tool), on page 2. Do you have any sample code beside http://bitbucket.org/galaxy/galaxy-central/wiki/DataSources? Thanks

2 1

Using rsyslog for logging from Galaxy
by Peter 05 Oct '10

05 Oct '10

Hi all, For our production server we are using rsyslog for centralised logging, http://www.rsyslog.com/ Galaxy is using "import logging" which can output to rsyslog, using SysLogHandler rather than StreamHandler or FileHandler. Based on grep'ing the source code Galaxy doesn't support this yet. I could probably add it but it isn't clear to me where this would be done... functions configure_logging() in lib/galaxy/config.py and in lib/galaxy/webapps/community/config.py look like strong possibilities but both allow for some global_conf_parser override (and I'm not sure what that does). Has anyone looked at modifying this area before, or could offer some tips? Thanks, Peter

2 5

Re: [galaxy-dev] [galaxy-user] Undocumented tags for tool configuration
by Kelly Vincent 04 Oct '10

04 Oct '10

Jelle, (I've copied this to galaxy-dev since it's more appropriate to that one) The data table approach is fairly new, so there aren't too many examples yet, although more tools are being converted and will be available soon in the distribution. Basically, there are 3 steps to using it: 1. Modify tool_data_table_conf.xml to specify: - the bowtie data table - the column types in the loc file - It should look something like this: <table name="bowtie_indexes"> <columns>name, value</columns> <file path="tool-data/bowtie_indices.loc" /> </table> 2. Create/modify the loc file to correspond with the column types specified in tool_data_table_conf.xml (in this example, the loc file doesn't have to be changed), though we are going to be changing the specification to <columns>value, dbkey, name, path</columns> 3. Modify the Bowtie wrapper to use the data table instead of the loc file directly, replacing this: <options from_file="bowtie_indices.loc"> <column name="value" index="1" /> <column name="name" index="0" /> </options> - with this: <options from_data_table="bowtie_indexes"/> The <actions> in the Bowtie wrapper is used in lieu of the deprecated <code> tag to set the dbkey of the output dataset. In bowtie_wrapper.xml, according to the first action block, if the refGenomeSource.genomeSource is "indexed" (not "history"), then it will assign the dbkey of the output file to be the same as that of the reference file. It does this by looking at through the loc file and finding the line that has the value that's been selected in the index dropdown box as column 1 of the loc file entry and using the dbkey, in column 0 (ignoring comment lines (starting with #) along the way). If refGenomeSource.genomeSource is "history", it resorts to default behavior for Galaxy, which is that the output is assigned the same value as the first input that has a dbkey specified. The second block would not be needed for most cases--it is required here to handle the specific case of a small reference file we use for functional testing. It says that if the dbkey has been set to "equCab2chrM" (that's what the <filter type="metadata_value"... column="1" /> tag) does then it should be changed to "equCab2" (the <option type="from_param" ... column="0" ...> tag does). If you need more information than this, let us know. Regards, Kelly On Oct 1, 2010, at 4:22 AM, Jelle Scholtalbers wrote: > Hey, > > I was looking through the bowtie_wrapper.xml to get some information > about how to use the tool_data_table_conf.xml. There I also noticed > in the output section the tag <actions>. > Is there any information on this tag as is does seem to be used a lot? > > Cheers, > Jelle > _______________________________________________ > galaxy-user mailing list > galaxy-user(a)lists.bx.psu.edu > http://lists.bx.psu.edu/listinfo/galaxy-user

2 1

Update .hgignore for typical Unix editor backup files
by Peter 01 Oct '10

01 Oct '10

Hi all, Would it make sense to add the following to the official .hgignore file to ignore backup files from common Unix editors, *~ *.swp *.bak Thanks, Peter

2 1

target in links
by Belinda M. Giardine 01 Oct '10

01 Oct '10

Am I missing something or is it not possible to set the target in the links from reStructuredText? It would be nice to be able to open help links in a separate window. Belinda

2 1