[galaxy-dev] New version of vcflib wrappers
The new version is based on vcflib 386afcaafd. GitHub -> https://github.com/nekrut/vcflib-tools ToolShed -> https://toolshed.g2.bx.psu.edu/view/anton/suite_vcflib_tools_3_0 These will be on test and main instances shortly. Any feedback is appreciated. anton -- Anton Nekrutenko Professor of Biochemistry and Molecular Biology http://nekrut.bx.psu.edu (814) 826-3051 ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] This looks like a Galaxy bug in installation of tools with a complex repository dependency.
Hi Folks, I've done a bit more work on this problem that I posted about on Friday. I'm working on streamlining the installation of two tools, one of which has a complex repository dependency on the other. FWIW, both tools are in the test tool shed, under visualization: xena_import has a complex repository dependency on start_xena. I know that it should not be necessary to specify the toolshed and changeset revision in tool_dependencies.xml when indicating the complex repository dependency. But here is what I observed. When I specified the changeset_revision and toolshed, the installation worked fine. When I removed the changeset_revision tag and reinstalled the tool, I experienced the bug detailed below, where a Google Chrome pop-up window told me that the repository installation failed, and after I clicked OK on the pop-up window, Galaxy seemed to go into an infinite state of indicating that the tool was "Cloning" and showing the same repeated POST commands in paster.log. When I put the changeset_revision tag back again, the tool installation worked just fine. Just to make sure that this wasn't all from some cruft hiding somewhere in my Galaxy installation, I started with a clean install today (including an 'hg update stable') and a clean shed_tools subdirectory. I hope this helps. In the meantime, thanks, everyone for all of your help! Melissa On Fri, Sep 12, 2014 at 12:02 PM, Melissa Cline wrote: > Thanks, folks! Everything you've said has clarified many things, and I'm > working on putting them into practice. But in the meantime, I've got a new > error condition, with the same repositories (and complex repository > dependencies), and could use some guidance. > > I started to see this error condition when I removed the toolshed and > changeset_revision tags in the tool_dependencies.xml for the dependent > repository xena_install. It now reads: > > > > > > > > > > > > > > Short and simple. But lately, when I try to install this repository from > the test toolshed, I get a pop-up window from Chrome (my web browser) that > says "The page at 127.0.0.1:8080 says:", "Initializing repository > installation failed", with an OK button. There is no error message visible > in paster.log. Here is what I do see: > > 127.0.0.1 - - [12/Sep/2014:11:45:57 -0700] "GET > /admin_toolshed/prepare_for_ins\ > > tall?tool_shed_url= > https://testtoolshed.g2.bx.psu.edu/&repository_ids=4ab1d3705\ > > ad0de2d&changeset_revisions=fe95cf1ae864 HTTP/1.1" 200 - "-" "Mozilla/5.0 > (Maci\ > > ntosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/37.\ > > 0.2062.94 Safari/537.36" > > tool_shed.galaxy_install.repository_dependencies.repository_dependency_manager > \ > > DEBUG 2014-09-12 11:46:05,937 Creating repository dependency objects... > > tool_shed.util.shed_util_common DEBUG 2014-09-12 11:46:07,214 Updating an > exist\ > > ing row for repository 'xena_import' in the tool_shed_repository table, > status \ > > set to 'New'. > > tool_shed.galaxy_install.repository_dependencies.repository_dependency_manager > \ > > DEBUG 2014-09-12 11:46:07,241 Skipping installation of revision > 75c7d80df9c1 of\ > > repository 'start_xena' because it was installed with the (possibly > updated) r\ > > evision 75c7d80df9c1 and its current installation status is 'Installed'. > > tool_shed.galaxy_install.repository_dependencies.repository_dependency_manager > \ > > DEBUG 2014-09-12 11:46:07,241 Building repository dependency > relationships... > > 127.0.0.1 - - [12/Sep/2014:11:46:05 -0700] "POST > /admin_toolshed/prepare_for_in\ > > stall HTTP/1.1" 200 - " > http://127.0.0.1:8080/admin_toolshed/prepare_for_install\ > > ?tool_shed_url= > https://testtoolshed.g2.bx.psu.edu/&repository_ids=4ab1d3705ad0d\ > > e2d&changeset_revisions=fe95cf1ae864" "Mozilla/5.0 (Macintosh; Intel Mac > OS X 1\ > > 0_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 > Safari/537.36\ > > " > > warning: testtoolshed.g2.bx.psu.edu certificate with fingerprint > 79:94:82:1f:74\ > > :e6:f8:5c:1c:b8:3e:8d:89:f0:0e:88:9a:ac:2b:61 not verified (check > hostfingerpri\ > > nts or web.cacerts config setting) > > 127.0.0.1 - - [12/Sep/2014:11:46:07 -0700] "POST > /admin_toolshed/manage_reposit\ > > ories HTTP/1.1" 500 - " > http://127.0.0.1:8080/admin_toolshed/prepare_for_install\ > > " "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 > (KHTML, li\ > > ke Gecko) Chrome/37.0.2062.94 Safari/537.36" > > Debug at: http://127.0.0.1:8080/_debug/view/1410547505 > > > Then when I click OK, the status of the tool changes to "Cloning", and > stays in that state indefinitely while paster.log keeps logging a repeat of > this message: > > 127.0.0.1 - - [12/Sep/2014:11:55:28 -0700] "POST > /admin_toolshed/repository_ins\ > > tallation_status_updates HTTP/1.1" 200 - " > http://127.0.0.1:8080/admin_toolshed/\ > > prepare_for_install" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) > AppleWebKi\ > > t/537.36 (KHTML,
Re: [galaxy-dev] Queueing system and job parameters
Hi Prakash, At this point, the documentation is the examples in job_resource_params_conf.xml.sample and job_conf.xml.sample. This code was in the August 2014 release, so you'll need to upgrade to use it. Here is the commit, which shows the changes to job_conf.xml.sample: https://bitbucket.org/galaxy/galaxy-central/commits/31b2924315d0b48fa7648ab4bfd04ef754829f71 --nate On Sun, Sep 14, 2014 at 8:34 AM, Velayutham, Prakash (Prakash) < prakash.velayut...@cchmc.org> wrote: > Hi Nate, > > Can you point me to the documentation that explains this in more detail? > What version of Galaxy supports this? My build is at least 3 months old, > probably even more. > > Thanks, > Prakash > > On Sep 11, 2014, at 1:17 PM, Nate Coraor wrote: > > Hi Prakash, > > You can use the relatively new job resource params feature to insert a > standard set of params on any tool form. See the example at: > > > https://bitbucket.org/galaxy/galaxy-central/src/tip/job_resource_params_conf.xml.sample > > Here is an example of how we're using it on the Galaxy Test server: > > > https://github.com/galaxyproject/usegalaxy-playbook/blob/master/files/galaxy/test.galaxyproject.org/config/job_resource_params_conf.xml > > https://github.com/galaxyproject/usegalaxy-playbook/blob/master/files/galaxy/test.galaxyproject.org/dynamic_rules/roundup_multi_walltime.py > > --nate > > > On Wed, Sep 10, 2014 at 8:57 PM, Velayutham, Prakash (Prakash) < > prakash.velayut...@cchmc.org> wrote: > >> Hi, >> >> I have a local Galaxy instance. I have tied the server to a local HPC and >> we use LSF for scheduling jobs. I was wondering how a user can submit a job >> from Galaxy while specifying a wall time and memory requirements for a job… >> Is this doable? >> >> Thanks, >> Prakash >> >> ___ >> 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/ >> >> To search Galaxy mailing lists use the unified search at: >> http://galaxyproject.org/search/mailinglists/ >> > > > ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Workflow step IDs: out of order?
I am not certain order_index solves all of the problems but I agree it
is a step forward and in the latest galaxy distribution the default is
to use 'order_index' instead of the old database id *IF* instead of
specifying inputs via the 'ds_map' parameter you specify the parameter
as 'inputs'. ('inputs' is a better name since collections can also now
be specified this way.) If using 'inputs' you can also specify
'inputs_by' as either 'step_index' (new default), 'step_identifier'
(old id used by 'ds_map'), or 'name' if your input datasets and
dataset collections have been given names. Names has the nice feature
of surviving many different changes to the workflow in the workflow
editor (even more than order_index), but the down side of 'name' is
that not everyone assigns input names.
I have created a blend4j issue
(https://github.com/jmchilton/blend4j/issues/20) to expose these new
options - hopefully I will get to that soon.
-John
On Sun, Sep 14, 2014 at 6:57 PM, Freek de Bruijn wrote:
> Hi everyone,
>
> The Galaxy API is a great way to interact with a Galaxy server and
> I've been using it to run workflows (supported by the blend4j library,
> since I'm working on a Java project). Recently, I ran into a challenge
> with the workflow step IDs.
>
> When retrieving the metadata of a Galaxy workflow (using the API and
> blend4j), the order of the workflow step IDs appears to be random (or
> at least, not what I expected). This makes it complicated to specify
> parameters when you run a workflow via the API, because the step ID
> and parameter name normally are a nice way to pick the parameter you
> want to set (blend4j method: WorkflowInputs.setStepParameter). Is is
> possible to determine which step ID is assigned to - for example - the
> second workflow step?
>
> >From a few tests and looking at the Galaxy source code, it looks to me
> like the workflow steps are sorted according to their position in the
> workflow editor (in ascending order of sqrt(sqr(position.x) +
> sqr(position.y))). When storing the workflow in the database, the ID
> field for each step is assigned a unique unpredictable number (by
> SQLAlchemy or the database?). But in addition to the ID, there is also
> a nice order_index field, which contains the indices in the expected
> order! Would it be possible to add the order_index field to the API
> and would that solve the step order issue?
>
> Cheers, Freek
> --
> Freek de Bruijn
> Scientific programmer | VU University medical center
> ___
> 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/
>
> To search Galaxy mailing lists use the unified search at:
> http://galaxyproject.org/search/mailinglists/
___
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/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Workflow step IDs: out of order?
Hi everyone, The Galaxy API is a great way to interact with a Galaxy server and I've been using it to run workflows (supported by the blend4j library, since I'm working on a Java project). Recently, I ran into a challenge with the workflow step IDs. When retrieving the metadata of a Galaxy workflow (using the API and blend4j), the order of the workflow step IDs appears to be random (or at least, not what I expected). This makes it complicated to specify parameters when you run a workflow via the API, because the step ID and parameter name normally are a nice way to pick the parameter you want to set (blend4j method: WorkflowInputs.setStepParameter). Is is possible to determine which step ID is assigned to - for example - the second workflow step? >From a few tests and looking at the Galaxy source code, it looks to me like the workflow steps are sorted according to their position in the workflow editor (in ascending order of sqrt(sqr(position.x) + sqr(position.y))). When storing the workflow in the database, the ID field for each step is assigned a unique unpredictable number (by SQLAlchemy or the database?). But in addition to the ID, there is also a nice order_index field, which contains the indices in the expected order! Would it be possible to add the order_index field to the API and would that solve the step order issue? Cheers, Freek -- Freek de Bruijn Scientific programmer | VU University medical center ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] find bam index files
Dear all For each bam file in my history I can download the associated bai (bam index) file. I assume these files are stored somewhere under /mount/galaxy/database/files/_metadata_files. Correct? Is there an easy way to find the bam index file for a bam file, given only the internal file name of the bam (e.g. /mont/galaxy/database/files/089/dataset_89231.dat)? I am asking because I would like to use the files_to_ftp tool to automatically download bams together with their associated indices. Thanks Ulf ** The information contained in the EMail and any attachments is confidential and intended solely and for the attention and use of the named addressee(s). It may not be disclosed to any other person without the express authority of Public Health England, or the intended recipient, or both. If you are not the intended recipient, you must not disclose, copy, distribute or retain this message or any part of it. This footnote also confirms that this EMail has been swept for computer viruses by Symantec.Cloud, but please re-sweep any attachments before opening or saving. http://www.gov.uk/PHE ** ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
