Re: [galaxy-dev] Mira-Assembler: DOESN'T WORK ON GALAXY
Hi Peter, Thanks for your response and for the advice from the other subscribers. I am not the site administrator, but I have passed on all the email correspondence to the administrators. I am a “wet-lab” scientist who wanted to use the programme for my work. That is why I use Galaxy as the script writing etc., is taken care of. Galaxy is a great resource for people like me. I’ll let you know what happens. Best regards, Marija On 23/08/2014 8:48 am, "Peter Cock" wrote: >On Fri, Aug 22, 2014 at 8:18 PM, Marija Atanaskovic > wrote: >> Hi Peter, >> >> I don¹t know what the stdout and stderr information was. I click on it >>but >> nothing comes up. >> >> I installed from the main toolshed: >> http://toolshed.g2.bx.psu.edu/view/peterjc/mira_assembler >> Yes, I did use the test toolshed for Mira 4. >> >> Regards, >> >> Marija > >If stdout and stderr are empty, this is consistent with MIRA never >even starting (as suggested by the next bit of information below). > >On Fri, Aug 22, 2014 at 8:20 PM, Marija Atanaskovic > wrote: >> Hi Peter, >> >> This is the error in history under MIRA log: >> >> tool error >> An error occurred with this dataset:Unable to run job due to a >> misconfiguration of the Galaxy job running system. Please contact a >>site >> administrator. >> >> Regards, >> >> Marija > >That suggests your Galaxy job runner is not properly configured, >and MIRA itself was never started. Are you the site administrator? >Are other Galaxy tools working? Are other Galaxy tools installed >from the ToolShed working? > >On Fri, Aug 22, 2014 at 8:22 PM, Marija Atanaskovic > wrote: >> Hi Peter, >> >> One more thing. The data that I am trying to analyse are fastq files of >> Ion Torrent reads. I have used them with other assemblers e.g., velvet, >> CLC. >> >> Marija > >I have not personally used Ion Torrent, but that ought to be fine. > >Peter > >P.S. You forgot to CC the mailing list. ___ 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] Concept for a Galaxy Versioned Fasta Data Retrieval Tool
We are about to implement a fasta database (file) versioning system as a Galaxy tool. I wanted to get interested people's feedback first before we roll ahead with the prototype implementation. The versioning system aims to: * Enable reproducible research: To recreate a search result at a certain point in time we need versioning so that search and mapping tools can look at sequence reference databases corresponding to a particular past date. This recall can also explain the difference between what was known in the past vs. currently. * Reduce hard drive space. Some databases are too big to keep N copies around, e.g. 5 years of 16S, updated monthly, is say, 670Mb + 668Mb + 665Mb + But occasionally we want to access past archives fairly quickly. * Integrate database versioning into Galaxy without adding a lot of complexity. A bonus would be to enable the efficient sharing of version databases between computers/servers. The solution we think would work centres around a "Versioned Data Retrieval" tool (draft image attached) that would work as follows: 1) User selects from a list of databases provided by "Shared Data > Data Libraries > Versioned Data". - Each database has a master file that keeps its various versions as a list of time-stamped insert/delete transactions of key (fasta id) value (description & sequence) pairs. - Each master file is managed outside of galaxy via a triggered process on regular fasta file imports from data sources like NCBI or other niche sources. - We're expecting, due to the nature of fasta archived sequence updates, that our master file would only be about 1.1x the latest version in size (uncompressed). 2) User enters date / version id to retrieve (validated) 3) If a cached version of that database exists, it is linked into user's history. 4) Otherwise a new version of it is created, placed in cache, and linked into history. - The cached version itself then shows up as linked data under a Data Library > Versioned Data subfolder. 5) User can select preconfigured workflow(s) to execute on the selected retreived fasta file to regenerate any database products they need. - Workflow output data would also be cached in the same way the fasta data is - by linking the Galaxy Data Library to it. - Workflow execution will be skipped if end data already exists in cache. - Simple makeblastdb or bowtie-build commands, or more specific workflows that include dustmasker etc can be implemented. Does this sound attractive? We're hoping such a vision could handle Fasta databases from 12mb to e.g. 200Gb (probably requires makeblastdb in parallel at that scale). Preliminary work suggests this project is doable via the Galaxy API without galaxy customization - does that sound right?! Feedback really appreciated! Regards, Damion Dooley Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada___ 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] Mira-Assembler: DOESN'T WORK ON GALAXY
On Fri, Aug 22, 2014 at 8:00 PM, Peter Cock wrote: > On Fri, Aug 22, 2014 at 9:39 AM, Marija Atanaskovic > wrote: > >> Also I can’t install Mira 4. This is the message I receive. >> Any suggestions. > > Getting "Internal Server Error" is unhelpful - I can't > really guess what might be going wrong here :( > This is a guess, but it could be you need to set the https_proxy in the /etc/environment file - see this thread: http://dev.list.galaxyproject.org/Internal-Server-Error-when-trying-to-install-a-tool-from-the-Tool-shed-tt4665361.html 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] Mira-Assembler: DOESN'T WORK ON GALAXY
On Fri, Aug 22, 2014 at 8:18 PM, Marija Atanaskovic wrote: > Hi Peter, > > I don¹t know what the stdout and stderr information was. I click on it but > nothing comes up. > > I installed from the main toolshed: > http://toolshed.g2.bx.psu.edu/view/peterjc/mira_assembler > Yes, I did use the test toolshed for Mira 4. > > Regards, > > Marija If stdout and stderr are empty, this is consistent with MIRA never even starting (as suggested by the next bit of information below). On Fri, Aug 22, 2014 at 8:20 PM, Marija Atanaskovic wrote: > Hi Peter, > > This is the error in history under MIRA log: > > tool error > An error occurred with this dataset:Unable to run job due to a > misconfiguration of the Galaxy job running system. Please contact a site > administrator. > > Regards, > > Marija That suggests your Galaxy job runner is not properly configured, and MIRA itself was never started. Are you the site administrator? Are other Galaxy tools working? Are other Galaxy tools installed from the ToolShed working? On Fri, Aug 22, 2014 at 8:22 PM, Marija Atanaskovic wrote: > Hi Peter, > > One more thing. The data that I am trying to analyse are fastq files of > Ion Torrent reads. I have used them with other assemblers e.g., velvet, > CLC. > > Marija I have not personally used Ion Torrent, but that ought to be fine. Peter P.S. You forgot to CC the mailing list. ___ 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] Database integrity error when installing new tools from toolshed
Hi Nate,
I'm thinking I misread the documentation on the restore part. What happened
was I pulled and updated that galaxy-dist repository and then when I got it
running after migrating the tools and updating the database schema to the
new version, it either didn't display my previous histories or I couldn't
download the files correctly (I'm thinking its the former but I don't
remember). This is where I tried restoring the database and once I did that
everything worked except for the tool installation part.
I checked the backup and it looks like the tool_version_association_id was
set to 79 instead of the current max in the table which should be 160. I
found these lines in my postgres backup.
--
-- Name: tool_version_association_id_seq; Type: SEQUENCE SET; Schema:
public; Owner: galaxy
--
SELECT pg_catalog.setval('tool_version_association_id_seq', 79, true);
Is it possible for me to backup and update the value of the sequence in the
database to resolve this?
Thanks for the help,
On Fri, Aug 22, 2014 at 8:46 AM, Nate Coraor wrote:
> On Aug 21, 2014, at 3:48 PM, Michael Ta wrote:
>
> Hi,
>
> I updated a local Galaxy installation a while back and I followed the
> steps listed on one of the wiki pages. The update included changes to the
> database schema and I was careful to backup and restore it according to the
> directions. However, when I try to install new tools from the tool shed or
> update a tool to a new revision it does not complete successfully. The
> following error appears in the log file.
>
> File '/home/galaxy/galaxy-dist/lib/tool_shed/util/tool_util.py', line 761
> in handle_tool_versions
> context.flush()
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/scoping.py',
>line 114 in do
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/session.py',
>line 1718 in flush
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/session.py',
>line 1789 in _flush
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/unitofwork.p
> y', line 331 in execute
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/unitofwork.p
> y', line 475 in execute
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.
> py', line 64 in save_obj
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.
> py', line 558 in _emit_insert_statements
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/base.py',
>line 1449 in execute
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/base.py',
>line 1584 in _execute_clauseelement
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/base.py',
>line 1698 in _execute_context
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/base.py',
>line 1691 in _execute_context
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/default.p
> y', line 331 in do_execute
> IntegrityError: (IntegrityError) duplicate key value violates unique
> constraint "tool_version_association_pk ey"
> DETAIL: Key (id)=(83) already exists.
> 'INSERT INTO tool_version_association (tool_id, parent_id) VALUES
> (%(tool_id)s, %(parent_id)s) RETURNING to ol_version_association.id'
> {'parent_id': 440, 'tool_id': 439}
>
> A few of the keys appear to be colliding with values already in the
> database, did I miss something when I updated and restored the database
> that is causing this?
>
>
> Hi Michael,
>
> The documentation should say to back up, but a restore is not necessary
> unless you encounter some problem during the migration. Could you point me
> at the documentation in question so I can update it?
>
> Could you check that your backup included the sequences and that when you
> restored the database, you restored the sequences? It looks like the
> sequence in question (tool_version_association_id_seq) is not actually set
> to the max(id) on the tool_version_association table, which means that the
> nextval selected from that sequence would conflict with an id already in
> the table.
>
> --nate
>
>
> Thanks,
> --
> Michael Ta
>
> ___
> 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] Database integrity error when installing new tools from toolshed
On Aug 21, 2014, at 3:48 PM, Michael Ta wrote:
> Hi,
>
> I updated a local Galaxy installation a while back and I followed the steps
> listed on one of the wiki pages. The update included changes to the database
> schema and I was careful to backup and restore it according to the
> directions. However, when I try to install new tools from the tool shed or
> update a tool to a new revision it does not complete successfully. The
> following error appears in the log file.
>
> File '/home/galaxy/galaxy-dist/lib/tool_shed/util/tool_util.py', line 761 in
> handle_tool_versions
> context.flush()
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/scoping.py',
> line 114 in do
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/session.py',
> line 1718 in flush
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/session.py',
> line 1789 in _flush
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/unitofwork.p
>y', line 331 in execute
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/unitofwork.p
>y', line 475 in execute
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.
>py', line 64 in save_obj
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/orm/persistence.
>py', line 558 in _emit_insert_statements
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/base.py',
> line 1449 in execute
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/base.py',
> line 1584 in _execute_clauseelement
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/base.py',
> line 1698 in _execute_context
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/base.py',
> line 1691 in _execute_context
> File
> '/home/galaxy/galaxy-dist/eggs/SQLAlchemy-0.7.9-py2.7-linux-x86_64-ucs4.egg/sqlalchemy/engine/default.p
>y', line 331 in do_execute
> IntegrityError: (IntegrityError) duplicate key value violates unique
> constraint "tool_version_association_pk ey"
> DETAIL: Key (id)=(83) already exists.
> 'INSERT INTO tool_version_association (tool_id, parent_id) VALUES
> (%(tool_id)s, %(parent_id)s) RETURNING to ol_version_association.id'
> {'parent_id': 440, 'tool_id': 439}
>
> A few of the keys appear to be colliding with values already in the database,
> did I miss something when I updated and restored the database that is causing
> this?
Hi Michael,
The documentation should say to back up, but a restore is not necessary unless
you encounter some problem during the migration. Could you point me at the
documentation in question so I can update it?
Could you check that your backup included the sequences and that when you
restored the database, you restored the sequences? It looks like the sequence
in question (tool_version_association_id_seq) is not actually set to the
max(id) on the tool_version_association table, which means that the nextval
selected from that sequence would conflict with an id already in the table.
--nate
>
> Thanks,
> --
> Michael Ta
>
> ___
> 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 and HTTPS User-authentification
On Aug 20, 2014, at 3:53 AM, Matthias Enders wrote: > Hi, > > I have a question regarding the user authentication of Galaxy. > > As to my knowledge galaxy uses http, also for the authentication, so the User > Email and the password are send in clear text. > > As I like to use Galaxy for user-authentication and due several disadvantages > not an external authentification like described here > (https://wiki.galaxyproject.org/Admin/Config/ExternalUserDatbases): > Is there any way of using https or an encryption-method for sending user > email and password. Hi Matthias, You can still serve Galaxy over HTTPS by placing it behind a proxy, even if you do not intend to perform authentication in the proxy. You'll just need to set X-URL-SCHEME in the proxy, as documented: For nginx: https://wiki.galaxyproject.org/Admin/Config/nginxProxy For Apache: https://wiki.galaxyproject.org/Admin/Config/ApacheProxy --nate > > With kind regards, > Matthias Enders > > ___ > 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] Internal Server Error when trying to install a tool from the Tool shed
Hi John, We resolved the toolshed download issue by adding an entry for https_proxy in our /etc/environment file. Thanks for all your help. Audrey On Wed, Aug 20, 2014 at 5:55 PM, audrey michel wrote: > Hi John, > > We also tried adding the proxy server ip address as follows to some hgrc > files (but this did not resolve the issue): > > > 1. Added the following to the hgrc file in /etc/mercurial/hgrc – : > > [http_proxy] > > host = X.X.X.X:8080 #ip address of our proxy server > > > 2. Also added the above two lines to the hgrc file in > /galaxy/galaxy-dist/.hg) > > > 3. We also created a .hgrc file in /home/galaxy/ with just the following > two lines: > > [http_proxy] > > host = X.X.X.X:8080 #ip address of our proxy server > > but none of the above resolved the toolshed download problem. > > > Maybe there are locations where we need to add the proxy server address? > > > Regards, > > Audrey > > > On Wed, Aug 20, 2014 at 5:05 PM, audrey michel > wrote: > >> Hi John, >> >> We are using Apache with the following configuration: >> >> #Configuration file for galaxy >> >> #ServerName localhost:80 >> ServerName X.X.X:80 #I have commented out our serverName for the >> purpose of this email >> DocumentRoot /mnt/workspace/DATA/galaxy >> RewriteEngine on >> #RewriteRule ^/galaxy$ /galaxy/ [R] >> RewriteRule ^/static/style/(.*) >> /galaxy-dist/static/june_2007_style/blue/$1 [L] >> RewriteRule ^/static/scripts/(.*) /galaxy-dist/static/scripts/packed/$1 >> [L] >> RewriteRule ^/static/(.*) /galaxy-dist/static/$1 [L] >> RewriteRule ^/favicon.ico /galaxy-dist/static/favicon.ico [L] >> RewriteRule ^/robots.txt /galaxy-dist/static/robots.txt [L] >> RewriteRule ^(.*) http://localhost:8080$1 [P] >> >> # Options +Includes >>#Order allow,deny >> Order deny,allow >> Deny from All >> Allow from X.X.X #I have commented out our subnet for >> the purpose of this email >>#Allow from All >> >> >> >> Thanks in advance for any suggestions, >> Audrey >> >> >> On Tue, Aug 19, 2014 at 8:53 PM, John Chilton >> wrote: >> >>> Hello Audrey, >>> >>> Please keep responses on list - it ensures people smarter than me >>> can respond :). Can you tell me what is sitting in front of Galaxy - >>> Apache, Nginx, uwsgi, etc... and send the configurations if possible? >>> I believe the out-of-the-box uwsgi configuration has some problems >>> with really long URL query strings which using the tool shed does >>> produce. >>> >>> -John >>> >>> >>> On Mon, Aug 18, 2014 at 11:56 AM, audrey michel >>> wrote: >>> > Hi John, >>> > >>> > We tried the following on another server where there is no proxy, and >>> we are >>> > able to install tools from this new instance: >>> > >>> > >>> > hg clone https://bitbucket.org/galaxy/galaxy-dist/ >>> > >>> > >>> > $ hg clone https://bitbucket.org/galaxy/galaxy-dist/ >>> > destination directory: galaxy-dist >>> > requesting all changes >>> > adding changesets >>> > adding manifests >>> > adding file changes >>> > added 14316 changesets with 48369 changes to 8546 files (+1 heads) >>> > updating to branch default >>> > 3597 files updated, 0 files merged, 0 files removed, 0 files unresolved >>> > >>> > We then modified just the admin_users, tool_dependency_dir, port and >>> > localhost. This was sufficient to allow us to use the toolshed to >>> install >>> > tools on this particular instance of galaxy. >>> > >>> > So it would appear to be a proxy issue with our other instance of >>> galaxy >>> > which is behind a proxy. Could you advise us on where we need to add >>> > http_proxy as we don't know which file(s) to add this to? We already >>> set the >>> > filter-with = proxy-prefix in the universe_wsgi.ini fiel. >>> > >>> > Thanks in advance, >>> > Audrey >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Mon, Aug 18, 2014 at 11:31 AM, audrey michel < >>> audreymann...@gmail.com> >>> > wrote: >>> >> >>> >> Hi John, >>> >> >>> >> Thanks for the suggestions. We are going to try a new install on one >>> of >>> >> our other servers and see if the problem occurs there or not. >>> >> >>> >> Will update you when we do this. >>> >> >>> >> Thanks. >>> >> Audrey >>> >> >>> >> >>> >> On Fri, Aug 15, 2014 at 8:20 PM, John Chilton >>> wrote: >>> >>> >>> >>> Okay - I am replying in thread but I not to your original message >>> >>> because there might be private stuff in the log you sent me. It looks >>> >>> like you were trying to install fastqdump from the main tool shed. So >>> >>> I setup a fresh Galaxy instance this morning and the only two things >>> I >>> >>> changed in the universe_wsgi.ini file were admin_users and >>> >>> tool_dependency_dir (required to install tool dependencies) and this >>> >>> install worked for me. Your error message had "Bad Status Line" in it >>> >>> - so it sounds like you were getting non-sense back from the tool >>> >>> shed. >>> >>> >>> >>> This could be because there is some proxy interfe
Re: [galaxy-dev] Problems downloading files via bioblend
Yes sorry about this - Eric reported this same problem this week.
bioblend is not using API endpoints to download datasets and this is a
problem for proxies with REMOTE_USER configured since most such
proxies are only configured to allow through requests on /api and this
is definitely not the route bioblend is using. I fixed a problem
earlier this week and know at least bioblend is consistently using the
wrong URL.
https://github.com/afgane/bioblend/commit/01c20b18df68f00c016ef28e9d8bac20435dbe31
I added an API endpoint for downloading datasets from Galaxy in
https://bitbucket.org/galaxy/galaxy-central/pull-request/131/implement-equivalent-of-dataset-display/diff
and I used it for some stuff - but it seems it has never made it into
bioblend. I will try to find some time to update bioblend to use this
- very sorry.
-John
On Thu, Aug 21, 2014 at 5:55 PM, Brad Zeitner
wrote:
> I have a python script that I use to download the qc data generated in one
> of the steps in a workflow.
> It used to work on a previous install of galaxy – but we’ve gone through and
> updated our Galaxy install so that it’s now running on a new file system -
> and when I try and use the bioblend api to download the dataset the request
> for the file gets redirected to the login page.
>
> The call to download it is -
> dm = gi.datasets.download_dataset(qcf.get("id"), outfile, False )
> Where qcf is the history step
> This calls the following url:/datasets/4fa2da3cf0e735a4/display?to_ext=html
>
> If I visit the url in a browser that’s not in a session, it behaves the same
> way – but works correctly when I am logged in.
> How can I access this using the api key? When I add the parameters
> key=${myKey} it still fails.
>
> Thanks,
> -Brad Zeitner
>
>
> --CONFIDENTIALITY NOTICE--: The information contained in this email is
> intended for the exclusive use of the addressee and may contain confidential
> information. If you are not the intended recipient, you are hereby notified
> that any form of dissemination of this communication is strictly prohibited.
> www.benaroyaresearch.org
>
> ___
> 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] Mira-Assembler: DOESN'T WORK ON GALAXY
On Fri, Aug 22, 2014 at 9:39 AM, Marija Atanaskovic wrote: > > Mira doesn’t work on Galaxy. This is the log message I receive. > > Tool: Assemble with MIRA v3.4 > Name: MIRA log > Created: Fri Aug 22 00:24:38 2014 (UTC) > Filesize: 0 bytes > Dbkey: ? > Format: txt > Galaxy Tool Version: 0.0.10 > Tool Version: None > Tool Standard Output: stdout > Tool Standard Error: stderr > Tool Exit Code: None > API ID: d5f55b83db1f410a > Full Path: /mnt/galaxy/files/000/dataset_326.dat > ... What was the stdout and stderr information? Did you install this from the main tool shed?: https://toolshed.g2.bx.psu.edu/view/peterjc/mira_assembler > Also I can’t install Mira 4. This is the message I receive. > Any suggestions. Getting "Internal Server Error" is unhelpful - I can't really guess what might be going wrong here :( I have had problems with the MIRA dependencies when Bastien has renamed folders on sourceforge... are you using the Test Tool Shed here (since I have not yet released the MIRA 4 wrapper on the main ToolShed)?: https://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler Regards, 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/
