Re: [galaxy-dev] Can a tool upload a .loc file that is then reused by subsequent versions of the tool?
Python code in galaxy tools can import all sorts of modules. Is there a way to add an extra path to the sys.path so that I can include some other python modules that way? I.e. in some galaxy python config file? I'd like to say in my tool code HTMLReportModule = __import__(html_template) ... htmlManager = HTMLReportModule.HTMLReport(tagGroup, options, query_stats) htmlManager.render(out_tabular_file, out_html_file) and in this way provide a switch from a standard report template that my galaxy tool has in its folder, to a custom one that a client has fiddled with and is comfortably outside galaxy's codespace. The html_template variable would have 'templates.html_report' for the stock template, but 'custom_templates.html_report' would pull it from wherever was set in the path. Seems like a secure approach. (I don't want to pass the paths via the browser). Thanks for your help! Damion ___ 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] understanding change of colours in history
Thanks for the help John. I am using a slightly older version of Galaxy. However, I was hoping that the change of colour may help me understand the name change in the history. For example when you upload a file i.e. test.txt, "test.txt" appears in the history. However, if you want the history text to say something like "uploaded file test.txt", then you can modify the method "new_history_upload" in ~/lib/galaxy/tools/actions/upload_common.py to update the text before calling "trans.app.model.HistoryDatasetAssociation" . This works as you can see this string when the file is being uploaded, however, when the file is uploaded and the history turns to green the history test says "test.txt" again. Do you have any idea where this may be set in the code? Thanks again Neil From: John Chilton [jmchil...@gmail.com] Sent: Thursday, April 10, 2014 11:39 PM To: Burdett, Neil (CCI, Herston - RBWH) Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] understanding change of colours in history This is tricky and has changed in the last few releases. If you have are developing against the latest revision of galaxy-central this is all handled via Backbone MVC code. In particular checkout the render method of static/scripts/mvc/dataset/hda-base.js about 100 lines down. The class of each of these HDA (history dataset) bodies is set based on the state fetched from the server: this.$el.empty() .attr( 'class', view.className ).addClass( 'state-' + view.model.get( 'state' ) ) .append( $newRender.children() ); The visual properties of this class are described by CSS (in static/style/blue/base.css which I think is actually a derived file based on this LESS file static/style/src/less/history.less). https://wiki.galaxyproject.org/Develop/CSS. Hope this helps. -John On Wed, Apr 9, 2014 at 11:44 PM, wrote: > Hi, > > Can someone point me in the direction of where the code in Galaxy is > called to change the history background for example when a job changes from > Yellow to red on error, or yellow to green on success. I've been going > around in circles now trying to figure out, how this is implemented and how > the labels are updated on the history. > > > > Also, If I change history_common.mako file and I restart the system my > changes aren't seen (i.e. add a new icon if the system goes into error) > > > > Thanks for any insight > > > > Neil > > > > > ___ > 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] trackster is not working on the vrelease_2014.02.10--2--29ce93a13ac7
Hello, I just updated to Feb.10 and also noticed that Trackster is not working. I too get the blank screen. Could you please tell me how to manually update the vis packed files? I do not know what these are. Thanks in advance, Liisa ___ 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] example_watch_folder.py problem importing file
Hello, I am testing the example_watch_folder.py script on my local instance of Galaxy (Feb.10 distribution). I have set up a simple workflow with the Fasta-to-Tabular tool. It takes a single input fasta file. Works in Galaxy UI. I have created input and output folders and followed the steps here http://gmod.827538.n3.nabble.com/Trouble-Shooting-example-watch-folder-py-td4030355.html But when I run the script and put a simple fasta file in the input folder I get the following error in the logs: galaxy.jobs.runners.drmaa DEBUG 2014-04-10 11:11:03,127 (1899) command is: python galaxy_dist_dev/tools/data_source/upload.py galaxy_dist_dev galaxy_dist_dev/database/tmp/tmpK40iV3galaxy_dist_dev/database/tmp/tmpx_5QyU 3802:galaxy_dist_dev/database/job_working_directory/001/1899/dataset_3802_files:galaxy_dist_dev/database/files/003/dataset_3802.dat; return_code=$?; cd galaxy_dist_dev; galaxy_dist_dev/set_metadata.sh ./database/files galaxy_dist_dev/database/job_working_directory/001/1899 . galaxy_dist_dev/universe_wsgi.ini galaxy_dist_dev/database/tmp/tmpK40iV3 galaxy_dist_dev/database/job_working_directory/001/1899/galaxy.json; sh -c "exit $return_code" galaxy.jobs.runners.drmaa DEBUG 2014-04-10 11:11:03,127 (1899) native specification is: -V -q all.q -l hostname="hostname.ca" galaxy.jobs.runners.drmaa INFO 2014-04-10 11:11:03,133 (1899) queued as 678390 galaxy.jobs DEBUG 2014-04-10 11:11:03,180 (1899) Persisting job destination (destination id: name_hwew) galaxy.jobs.runners.drmaa DEBUG 2014-04-10 11:11:03,579 (1899/678390) state change: job is running 10.1.1.111 - - [10/Apr/2014:11:11:07 -0400] "POST /api/workflows?key=dd3916dfb37dffc08f070f1e3503015a HTTP/1.1" 200 - "-" "Python-urllib/2.6" galaxy.jobs.runners.drmaa DEBUG 2014-04-10 11:11:07,778 (1899/678390) state change: job finished normally galaxy.jobs DEBUG 2014-04-10 11:11:08,082 setting dataset state to ERROR galaxy.jobs DEBUG 2014-04-10 11:11:08,227 job 1899 ended galaxy.datatypes.metadata DEBUG 2014-04-10 11:11:08,227 Cleaning up external metadata files galaxy.jobs DEBUG 2014-04-10 11:11:08,652 (1900) Working directory for job is: galaxy_dist_dev/database/job_working_directory/001/1900 galaxy.datatypes.metadata DEBUG 2014-04-10 11:11:08,770 Cleaning up external metadata files galaxy.jobs.handler INFO 2014-04-10 11:11:08,795 (1900) Job unable to run: one or more inputs in error state 10.202.22.186 - - [10/Apr/2014:11:11:31 -0400] "GET /history/list HTTP/1.1" 200 - "http://galaxy.server.ca:8080/root"; "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0" And in the dataset itself in the resulting Galaxy history UI WARNING:galaxy.datatypes.registry:Overriding conflicting datatype with extension 'asn1', using datatype from galaxy_dist_dev/database/tmp/tmpK40iV3. Yesterday, before I did the upgrade to Feb.10. The input files would import (as a green dataset in the History UI) put be empty and say 'no peak' Thanks in advance for any help, Liisa ___ 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] enforcing minimum length on text params
Hi Ravi, for that you need a regex validator: https://bitbucket.org/galaxy/galaxy-central/src/tip/lib/galaxy/tools/parameters/validation.py#cl-27 e.g. .*\S Best, Nicola Il giorno gio, 10/04/2014 alle 10.20 -0400, Sanka, Ravi ha scritto: > Hi Nicola, > > Perchance, do you know what type of validator I can put to ensure that the > string input is does not consist of only whitespace? Such a string is > still invalid for my tool, but counts as a string. > > -- > Ravi Sanka > ICS Sr. Bioinformatics Engineer > J. Craig Venter Institute > 301-795-7743 > -- > > > > > On 4/9/14 2:35 PM, "Sanka, Ravi" wrote: > > >Hi Nicola, > > > >Thank you. I tried the validator as you illustrated, and it worked > >perfectly. > > > >-- > >Ravi Sanka > >ICS Sr. Bioinformatics Engineer > >J. Craig Venter Institute > >301-795-7743 > >-- > > > > > > > > > >On 4/9/14 11:06 AM, "Nicola Soranzo" wrote: > > > >>Il 2014-04-09 17:00 Sanka, Ravi ha scritto: > >>> Greetings, > >>> > >>> I am adding a new tool to our in-house Galaxy, which has a few string > >>> inputs. I have made each one a text param in the XML, but want to > >>> ensure that the user does not leave any empty when he executes the > >>> tool. > >>> > >>> How can I do this? I tried setting the optional field of each text > >>> param to false, but that doesn't work since, technically, an empty > >>> string still counts as a string. > >>> > >>> Is there a minimum length setting I can enforce? > >> > >>Hi Ravi, > >>you should use a validator, as in the following example: > >> > >> > >> > >> > >> > >>Best, > >>Nicola > > > ___ 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] enforcing minimum length on text params
Hi Nicola, Perchance, do you know what type of validator I can put to ensure that the string input is does not consist of only whitespace? Such a string is still invalid for my tool, but counts as a string. -- Ravi Sanka ICS Sr. Bioinformatics Engineer J. Craig Venter Institute 301-795-7743 -- On 4/9/14 2:35 PM, "Sanka, Ravi" wrote: >Hi Nicola, > >Thank you. I tried the validator as you illustrated, and it worked >perfectly. > >-- >Ravi Sanka >ICS Sr. Bioinformatics Engineer >J. Craig Venter Institute >301-795-7743 >-- > > > > >On 4/9/14 11:06 AM, "Nicola Soranzo" wrote: > >>Il 2014-04-09 17:00 Sanka, Ravi ha scritto: >>> Greetings, >>> >>> I am adding a new tool to our in-house Galaxy, which has a few string >>> inputs. I have made each one a text param in the XML, but want to >>> ensure that the user does not leave any empty when he executes the >>> tool. >>> >>> How can I do this? I tried setting the optional field of each text >>> param to false, but that doesn't work since, technically, an empty >>> string still counts as a string. >>> >>> Is there a minimum length setting I can enforce? >> >>Hi Ravi, >>you should use a validator, as in the following example: >> >> >> >> >> >>Best, >>Nicola > ___ 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] LWR Support
On Wed, Apr 9, 2014 at 9:55 AM, Alexandre Defelicibus wrote: > Hi all, > > I have some doubts about how to configure a LWR server on Linux. > I have read the LWR documentation, however how to configure the LWR is not > clear to me. > > This is my scenario: > > On my Galaxy server I have some tools that I would like to send their jobs > to the LWR server. These tools are at the same folder (xml and py). > > The LWR server is installed on Linux, and it is accessible through the URL. > > This is my job_conf.xml: > > > > > load="galaxy.jobs.runners.lwr:LwrJobRunner"> > > > > > > > > > http://200.144.255.42:8005/ > > > > > > > 2 > 1 > 24:00:00 > 1 > > > > When I execute the tool, I get this error: > > ValueError: No JSON object could be decoded > > > At the LWR server, I use a nginx server, and I see on the log file that the > server receive this URL: > GET /setup?tool_id=2pg&job_id=24&tool_version=1.0.0 Cool I have never setup LWR behind nginx but it should certainly work. > > So, I concluded that the Galaxy server is accessing the LWR server and > creating a job, but something wrong happens on the LWR side, but I couldn't > realize what is missing. How are you running the LWR? There should be a file called paster.log in the LWR root directory or in the standard out of the terminal session you started the LWR using if it did not start as a daemon. That should have a lot of relevant details. Basically there should be a bunch of lines in Galaxy's log and the LWR log corresponding to the attempted submission that will hopefully provide some details related to the error. > > So, I have some questions to ask: > > - Do I need to have a Galaxy instance running at the same server of LWR? No this definitely should not be needed. > - Are there other variables that I should have set on Galaxy or on LWR > server? Not really > - I know it is better if I use the secure LWR, and I will do, but is there > something wrong on my job_conf.xml file? Nothing jumps out at me. The logs will make it clear if there is though I think. The LWR is distributed with a test script to exercise the server independent of Galaxy - you should target it at your nginx proxy to determine if the problem is with above the proxy (i.e. in Galaxy's configuration or the tool itself) or below it (either in the LWR, nginx, etc...). >From the LWR root you should be able to just run: python run_client_tests.py --url http://200.144.255.42:8005/ You could also clone down the LWR code on your Galaxy host and run this to determine if there is some firewall problem for instance. Hope this helps and thanks for your interest in the LWR! -John > > I hope I have shown all the needed details about my installation. > > Best regards, > > Alexandre > > -- > Alexandre Defelicibus > Mestrando em Bioengenharia > Programa de Pós-Graduação em Bioengenharia > Universidade de São Paulo - USP > > ___ > 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] Launching a workflow via API, multiple params for one tool
Ah, yes. That seems to have been added a couple months ago. The BioTeam
appliance just missed that update by a week or two. I’ll go bug them. Thanks.
FWIW, I am using bioblend, and I got my example from the bioblend documentation:
http://bioblend.readthedocs.org/en/latest/api_docs/galaxy/all.html#module-bioblend.galaxy.workflows
-john
On Apr 10, 2014, at 5:42 AM, Nicola Soranzo wrote:
> Il 2014-04-09 22:18 John Marmaduke Eppley ha scritto:
>> As far as I can figure out, the parameter map for running a workflow
>> via the API is supposed to look like this:
>>
>> {'blastn': {'param': 'evalue', 'value': '1e-06’}}
>>
>> This doesn’t seem to allow for multiple parameters to a single tool.
>> Is there a way to submit multiple parameters that I’m missing? For
>> example:
>>
>> {'blastn': {'param': 'evalue', 'value': '1e-06’, 'param':
>> ‘identity_cutoff’, ‘value’: ’70’}}
>>
>> …will not work. The dict() container doesn’t allow duplicate keys,
>> it just overwrites the values.
>
> Hi John,
> you are using the old and deprecated syntax, you can use instead:
>
> {'blastn': {'evalue': '1e-06', 'identity_cutoff': 70}}
>
> For more details look at _update_step_parameters() function documentation:
>
> https://bitbucket.org/galaxy/galaxy-dist/src/tip/lib/galaxy/webapps/galaxy/api/workflows.py
>
> Or look at this complete example:
>
> https://github.com/crs4/bioblend/blob/objects/docs/examples/w5_galaxy_api.py
>
> Moreover, you may consider using the more high-level bioblend API:
>
> http://bioblend.readthedocs.org/en/latest/
>
> Best,
> Nicola
> ___
> 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/
smime.p7s
Description: S/MIME cryptographic signature
___
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] understanding change of colours in history
This is tricky and has changed in the last few releases. If you have are developing against the latest revision of galaxy-central this is all handled via Backbone MVC code. In particular checkout the render method of static/scripts/mvc/dataset/hda-base.js about 100 lines down. The class of each of these HDA (history dataset) bodies is set based on the state fetched from the server: this.$el.empty() .attr( 'class', view.className ).addClass( 'state-' + view.model.get( 'state' ) ) .append( $newRender.children() ); The visual properties of this class are described by CSS (in static/style/blue/base.css which I think is actually a derived file based on this LESS file static/style/src/less/history.less). https://wiki.galaxyproject.org/Develop/CSS. Hope this helps. -John On Wed, Apr 9, 2014 at 11:44 PM, wrote: > Hi, > > Can someone point me in the direction of where the code in Galaxy is > called to change the history background for example when a job changes from > Yellow to red on error, or yellow to green on success. I've been going > around in circles now trying to figure out, how this is implemented and how > the labels are updated on the history. > > > > Also, If I change history_common.mako file and I restart the system my > changes aren't seen (i.e. add a new icon if the system goes into error) > > > > Thanks for any insight > > > > Neil > > > > > ___ > 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] Bowse button on upload data tool page...
This is implemented by the web browser. http://en.wikipedia.org/wiki/File_select File tool parameters are rendered by tool_form.mako in such a way that the web browser takes over and allows users to select files. One is very constrained about how customized one can make this as a security mechanism - to protected users and their hard drives from websites. -John On Thu, Apr 10, 2014 at 12:25 AM, wrote: > Hi, > how is the "Browse..." button implemented on the data upload tool page? > > When you click on it you get a new window appearing so you can select files > to upload. > > Does anyone know where is the "Browse..." button is defined/implemented in > the code? I thought it would be in > "./templates/webapps/galaxy/tool_form.mako" but can't see any references to > it > > Thanks foir any help > > Neil > > ___ > 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] [galaxy-user] Trackster error on dbkeys
(Moved to galaxy-dev mailing list because it concerns server admin rather than
Galaxy usage.)
If everything worked fine with a human build but not for PF3d7, then my guess
is that the len file for PF3d7 isn’t correctly formatted. Right now, the file
parser is very unforgiving—no extra spaces or lines are allowed.
If you check the len file and don’t spot an issue, please send to it to me and
I’ll take a look.
Best,
J.
--
Jeremy Goecks
Assistant Professor of Computational Biology
George Washington University
On Apr 10, 2014, at 2:30 AM, Aarthi Mohan wrote:
> Hi all,
>
> I am setting up galaxy on a server running CentOS 6.5.
> I found that Trackster application hits me with an error
> "Could not load chroms for this dbkey: PF3D7", when I try "add new track"
> from Visualization.
>
> I am working with Plasmodium falciparum (PF3d7) genome, and I followed the
> instruction for setting visualization from
> "https://wiki.galaxyproject.org/Visualization%20Setup"; and placed the 2bit,
> len files in the appropriate path.
>
> I have also made sure the genome build is present in the builds.txt under
> tool-data/shared/ucsc.
>
> For a test, I have the human chromosomes len files and Trackster loads it
> without any problem.
>
> Any suggestion would greatly help me.
>
> Thanks
> RT
>
> Log file:
> ---
> 127.0.0.1 - - [10/Apr/2014:12:29:44 +0800] "GET /visualization/trackster
> HTTP/1.1" 200 - "http://127.0.0.1:8081/"; "Mozilla/5.0 (X11; Linux x86_64;
> rv:24.0) Gecko/20100101 Firefox/24.0"
> 127.0.0.1 - - [10/Apr/2014:12:29:45 +0800] "GET /api/genomes?chrom_info=True
> HTTP/1.1" 200 - "http://127.0.0.1:8081/visualization/trackster"; "Mozilla/5.0
> (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
> 127.0.0.1 - - [10/Apr/2014:12:29:51 +0800] "GET
> /api/genomes/PF3D7?low=0&num=100 HTTP/1.1" 500 -
> "http://127.0.0.1:8081/visualization/trackster"; "Mozilla/5.0 (X11; Linux
> x86_64; rv:24.0) Gecko/20100101 Firefox/24.0"
> Error - : list index out of range
> URL: http://127.0.0.1:8081/api/genomes/PF3D7?low=0&num=100
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/lib/galaxy/web/framework/middleware/error.py',
> line 149 in __call__
> app_iter = self.application(environ, sr_checker)
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/eggs/Paste-1.7.5.1-py2.6.egg/paste/recursive.py',
> line 84 in __call__
> return self.application(environ, start_response)
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/eggs/Paste-1.7.5.1-py2.6.egg/paste/httpexceptions.py',
> line 633 in __call__
> return self.application(environ, start_response)
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/lib/galaxy/web/framework/base.py',
> line 132 in __call__
> return self.handle_request( environ, start_response )
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/lib/galaxy/web/framework/base.py',
> line 190 in handle_request
> body = method( trans, **kwargs )
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/lib/galaxy/web/framework/__init__.py',
> line 78 in decorator
> return to_json_string( func( self, trans, *args, **kwargs ) )
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/lib/galaxy/webapps/galaxy/api/genomes.py',
> line 42 in show
> rval = self.app.genomes.chroms( trans, dbkey=id, num=num, chrom=chrom,
> low=low )
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/lib/galaxy/visualization/genomes.py',
> line 292 in chroms
> rval = genome.to_dict( num=num, chrom=chrom, low=low )
> File
> '/data/maarthi/Galaxy/Test/galaxy-dist/lib/galaxy/visualization/genomes.py',
> line 153 in to_dict
> chroms[ fields[0] ] = int( fields[1] )
> IndexError: list index out of range
>
>
> CGI Variables
> -
> CONTENT_LENGTH: '0'
> HTTP_ACCEPT: 'application/json, text/javascript, */*; q=0.01'
> HTTP_ACCEPT_ENCODING: 'gzip, deflate'
> HTTP_ACCEPT_LANGUAGE: 'en-US,en;q=0.5'
> HTTP_CONNECTION: 'keep-alive'
> HTTP_COOKIE:
> 'galaxysession=c6ca0ddb55be603abc74375a63eca6a53211ad8efeb084140a6e95d9de0824b221b12b4bbc465351'
> HTTP_HOST: '127.0.0.1:8081'
> HTTP_REFERER: 'http://127.0.0.1:8081/visualization/trackster'
> HTTP_USER_AGENT: 'Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
> Firefox/24.0'
> HTTP_X_REQUESTED_WITH: 'XMLHttpRequest'
> PATH_INFO: '/api/genomes/PF3D7'
> QUERY_STRING: 'low=0&num=100'
> REMOTE_ADDR: '127.0.0.1'
> REQUEST_METHOD: 'GET'
> SERVER_NAME: '0.0.0.0'
> SERVER_PORT: '8081'
> SERVER_PROTOCOL: 'HTTP/1.1'
>
>
> WSGI Variables
> --
> application:
> is_api_request: True
> paste.cookies: ( galaxysession='c6ca0ddb55be603abc74375a63eca6a53211ad8efeb084140a6e95d9de0824b221b12b4bbc465351'>,
>
> 'galaxysession=c6ca0ddb55be603abc74375a63eca6a53211ad8efeb084140a6e95d9de0824b221b12b4bbc465351')
> paste.expected_exceptions: []
> paste.httpexceptions: 0x748eed0>
> paste.httpserver.thread_pool: 0x795c310>
> paste.parsed_querystring: ([('low', '0'), ('num', '100')], 'low=0&num=100')
> paste.recurs
Re: [galaxy-dev] Using Galaxy ToolShed API for uploading a tar-ball
Hi Peter, This is not yet available, but we'll certainly implement it. I've created this Trello card for it. https://trello.com/c/fykf8IPO/197-enhance-api-to-enable-tar-archive-uploads Thanks! Greg Von Kuster On Apr 10, 2014, at 7:50 AM, Peter Cock wrote: > Hi all, > > I've just skimmed Greg's latest blog post which is about > the REST API for the ToolShed: > http://gregvonkuster.org/galaxy-tool-shed-restful-api/ > > I would be interested in automating pushing updates to the > ToolShed, which I currently do manually by uploading a > tar-ball. Is it possible yet to upload a tar-ball via the API? > > Thanks, > > 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/ > > 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] Using Galaxy ToolShed API for uploading a tar-ball
Hi all, I've just skimmed Greg's latest blog post which is about the REST API for the ToolShed: http://gregvonkuster.org/galaxy-tool-shed-restful-api/ I would be interested in automating pushing updates to the ToolShed, which I currently do manually by uploading a tar-ball. Is it possible yet to upload a tar-ball via the API? Thanks, 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Launching a workflow via API, multiple params for one tool
Il 2014-04-09 22:18 John Marmaduke Eppley ha scritto:
As far as I can figure out, the parameter map for running a workflow
via the API is supposed to look like this:
{'blastn': {'param': 'evalue', 'value': '1e-06’}}
This doesn’t seem to allow for multiple parameters to a single tool.
Is there a way to submit multiple parameters that I’m missing? For
example:
{'blastn': {'param': 'evalue', 'value': '1e-06’, 'param':
‘identity_cutoff’, ‘value’: ’70’}}
…will not work. The dict() container doesn’t allow duplicate keys,
it just overwrites the values.
Hi John,
you are using the old and deprecated syntax, you can use instead:
{'blastn': {'evalue': '1e-06', 'identity_cutoff': 70}}
For more details look at _update_step_parameters() function
documentation:
https://bitbucket.org/galaxy/galaxy-dist/src/tip/lib/galaxy/webapps/galaxy/api/workflows.py
Or look at this complete example:
https://github.com/crs4/bioblend/blob/objects/docs/examples/w5_galaxy_api.py
Moreover, you may consider using the more high-level bioblend API:
http://bioblend.readthedocs.org/en/latest/
Best,
Nicola
___
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] Jobs deleted staying in 'dr' status
Il 2013-10-11 17:21 Sytchev, Ilya ha scritto: On 9/12/13 10:35 AM, "Peter Cock" wrote: On Thu, Sep 12, 2013 at 2:01 PM, Mathieu Bahin wrote: Hi all, We have been developing our own Galaxy instance for a while now. We have a cluster on which the job are sent to be executed, it is managed through SGE. Usually, communication between SGE and DRMAA is ok and we don't have any problem with that. When a job is deleted by the user, most of the times, the job disappears but sometimes, we don't know why, the job stays and has the status 'dr' within SGE. If we don't kill it 'manually', it stays forever. It is not always the same tools which produces this error. Have you any idea why how manage it ? I have noticed problem with our DRMMA/SGE setup where a user can cancel a large job (using the job splitter in at least some cases), but Galaxy does not seem to cancel the jobs on the cluster. I've not tried to diagnose this yet - it could be a similar issue though. Also, in our DRMAA/LSF setup (using a fork of the latest galaxy-dist) jobs generated by the current workflow step continue running on the cluster after history is deleted. Ilya Hi Ilya, I also see this behaviour with DRMAA/GridEngine. I think this has been already reported: https://trello.com/c/1whC9did/245-currently-running-jobs-in-deleted-histories-should-be-killed Please upvote it! Best, Nicola ___ 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/
