[galaxy-dev] workflow Editor
Hi, I want to know about workflow editor and how it works internally? what type of canvas editor are you using ? doest it support only python environment ? if you have any documents related with ,can i get it . Regards shashi --- This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- ___ 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/
[galaxy-dev] History not updating automatically
Hi list, I have a weird problem after updating to the latest version. After doing the update as usual, the history panel is not updating automatically anymore. And when I press refresh, I get an javascript popup saying: Error getting history updates from the server. Forbidden Also, in the log I see the following: galaxy.web.framework WARNING 2013-01-28 12:30:01,673 User logged in as '(null)' externally, but has a cookie as 'sa...@embl.de' invalidating session We are using LDAP to connect to Galaxy, but I don't know if this has something to do with the problem. As I said, it was working perfectly fine before the update. Does someone know the problem or has any ideas? Thanks for your help, Sajoscha ___ 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/
[galaxy-dev] Uploading large files as Admin Still slow!
Hi, I am trying to upload 2x 2.5GB files to my data libraries (in Admin on a local instance) but it has so far been running over night and not completed. How can I speed this up? Can I upload compressed files? Can I not just copy these files directly in to $galaxy-dist/database/files/000 ? Thanks, Jack ___ 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/
Re: [galaxy-dev] Uploading large files as AdminŠ Still slow!
What probably happened here is that due to the filesize, the browser upload failed but this went undetected. The good news is that you *can* tell galaxy to copy directly, or you could even use the files exactly where they are without any copy. What you want to do is enable this section in your universe_wsgi.ini, and then restart galaxy, after which you'll be able to just paste in the local path and galaxy will handle the rest. # Add an option to the admin library upload tool allowing admins to paste # filesystem paths to files and directories in a box, and these paths will be # added to a library. Set to True to enable. Please note the security # implication that this will give Galaxy Admins access to anything your Galaxy # user has access to. #allow_library_path_paste = False -Dannon On Jan 28, 2013, at 8:21 AM, Jackie Lighten jackie.ligh...@dal.ca wrote: Hi, I am trying to upload 2x 2.5GB files to my data libraries (in Admin on a local instance) but it has so far been running over night and not completed. How can I speed this up? Can I upload compressed files? Can I not just copy these files directly in to $galaxy-dist/database/files/000 ? Thanks, Jack ___ 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/ ___ 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/
[galaxy-dev] Nice 'citable' URLs for Galaxy Tool Shed repositories
Dear all, Something I am conscious of every time I have directed someone to a tool or wrapper on the Galaxy Tool Shed is the lack of nice stable URLs. The current frame based design hinders this - and as a result I usually just have to give the ToolShed URL and tell them what to search for. This problem is particularly acute for citing a tool shed entry, where a nice URL would be far better. I appreciate moving away from the current frame interface is a lot of work - although what Jeremy Goecks wrote last week suggests that is a long term goal: http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-January/012792.html I would like something similar to the repository URL, but for the ToolShed interface. e.g. The repository view for my MIRA wrapper: http://toolshed.g2.bx.psu.edu/repos/peterjc/mira_assembler Perhaps is the short-term what could be done is to enhance the repository view, and include links between this and the current Tool Shed frame based page? That way we can share a nice URL like http://toolshed.g2.bx.psu.edu/repos/peterjc/mira_assembler to direct someone to a resource in the Tool Shed? e.g. (1) When viewing an entry on the Tool Shed, include a prominent link to the repository URL (perhaps even with social media links like tweet or share this to emphasise this is the best URL to share). (2) In the header for each repo (perhaps in place of the current Mercuiral logo?) have a link to the Tool Shed frameset for the tool being viewed. 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/
Re: [galaxy-dev] Uploading large files as AdminŠ Still slow!
Thanks. I now have the option to upload via directory path. How do I create the ability to use files in their current location without a copy into Galaxy database ? Thanks, J On 2013-01-28 9:30 AM, Dannon Baker dannonba...@me.com wrote: What probably happened here is that due to the filesize, the browser upload failed but this went undetected. The good news is that you *can* tell galaxy to copy directly, or you could even use the files exactly where they are without any copy. What you want to do is enable this section in your universe_wsgi.ini, and then restart galaxy, after which you'll be able to just paste in the local path and galaxy will handle the rest. # Add an option to the admin library upload tool allowing admins to paste # filesystem paths to files and directories in a box, and these paths will be # added to a library. Set to True to enable. Please note the security # implication that this will give Galaxy Admins access to anything your Galaxy # user has access to. #allow_library_path_paste = False -Dannon On Jan 28, 2013, at 8:21 AM, Jackie Lighten jackie.ligh...@dal.ca wrote: Hi, I am trying to upload 2x 2.5GB files to my data libraries (in Admin on a local instance) but it has so far been running over night and not completed. How can I speed this up? Can I upload compressed files? Can I not just copy these files directly in to $galaxy-dist/database/files/000 ? Thanks, Jack ___ 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/ ___ 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/
Re: [galaxy-dev] Uploading large files as AdminŠ Still slow!
Sorry. I got it O the drop down menu. Thanks again. J On 2013-01-28 9:30 AM, Dannon Baker dannonba...@me.com wrote: What probably happened here is that due to the filesize, the browser upload failed but this went undetected. The good news is that you *can* tell galaxy to copy directly, or you could even use the files exactly where they are without any copy. What you want to do is enable this section in your universe_wsgi.ini, and then restart galaxy, after which you'll be able to just paste in the local path and galaxy will handle the rest. # Add an option to the admin library upload tool allowing admins to paste # filesystem paths to files and directories in a box, and these paths will be # added to a library. Set to True to enable. Please note the security # implication that this will give Galaxy Admins access to anything your Galaxy # user has access to. #allow_library_path_paste = False -Dannon On Jan 28, 2013, at 8:21 AM, Jackie Lighten jackie.ligh...@dal.ca wrote: Hi, I am trying to upload 2x 2.5GB files to my data libraries (in Admin on a local instance) but it has so far been running over night and not completed. How can I speed this up? Can I upload compressed files? Can I not just copy these files directly in to $galaxy-dist/database/files/000 ? Thanks, Jack ___ 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/ ___ 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/
Re: [galaxy-dev] Selecting Intermediary Files in a Workflow
You can work around this using the from_work_dir attribute when specifying the output file in your tool config. -- jt (composed on my phone) On Jan 27, 2013, at 6:13 PM, Peter Cock p.j.a.c...@googlemail.com wrote: On Sun, Jan 27, 2013 at 10:26 PM, Kolby Chien kc...@nau.edu wrote: Hello, I've been working with a local installation of Galaxy and my question is about how Galaxy chooses which file to use in the next step of the workflow. I have created a custom file type called cub which is required for my custom tools and I have added this custom file type into the extension list. When I run the first step of my workflow, Galaxy will create an intermediate cub file called dataset_51.dat.cub containing my processed data, but also an empty intermediate dat file as well of the same name sans cub extension (dataset_51.dat) . The next tool in the workflow requires a cub file type input, but instead of using the cub file, it chooses to process the empty .dat file instead, causing the tool to process incorrectly. I've looked over some settings and double checked that my tool xml files specify cub as the output file type and as the input file type for the next tool, but now I am at a loss. Is there anyway to specify to Galaxy that the cub file should be used in the next step of the workflow instead of the dat file? Galaxy wants all the files to use the names Galaxy tells the tool, and those filenames all end with .dat - the problem is probably Galaxy has told you (i.e. your tool) to use dataset_51.dat as the output file, but your tool has instead used dataset_51.dat.cub (which Galaxy will ignore). 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/ ___ 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/
Re: [galaxy-dev] workflow Editor
The client side of the workflow editor is in javascript, using a mix of HTML5 Canvas and DOM elements. It communicates with the server using JSON. The server side is written in Python. The editor could be decoupled and reused, however there are some details that are fairly Galaxy specific right now (particularly how tool states -- the values of the various input parameters -- are encoded). -- James Taylor, Assistant Professor, Biology/CS, Emory University On Mon, Jan 28, 2013 at 5:17 AM, ssha...@cdac.in wrote: Hi, I want to know about workflow editor and how it works internally? what type of canvas editor are you using ? doest it support only python environment ? if you have any documents related with ,can i get it . Regards shashi --- This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. --- ___ 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/ ___ 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/
[galaxy-dev] workflows stop prematurely
Hi All On my local install of galaxy I'm having problems executing workflows. I will upload data into a new history and then select to run a saved workflow. This initiates fine but, after the completion of a variable number of steps, the workflow just stops after the successful completion of a step. No errors appear in the web interface and all I can see in the paster.log is something like 90 HTTP/1.1 200 - http://127.0.0.1:8081/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 127.0.0.1 - - [28/Jan/2013:12:29:07 -0400] GET /api/histories/82b264d8c3d11790 HTTP/1.1 200 - http://127.0.0.1:8081/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 galaxy.jobs.runners.local DEBUG 2013-01-28 12:29:08,621 execution finished: python /home/rosema1/Projects/galaxy-dist/tools/fastq/fastq_trimmer_by_quality.py '/home/rosema1/Projects/galaxy-dist/database/files/000/dataset_590.dat' '/home/rosema1/Projects/galaxy-dist/database/files/000/dataset_592.dat' -f 'sanger' -s '5' -t '1' -e '53' -a 'mean' -x '0' -c '=' -q '20.0' galaxy.jobs DEBUG 2013-01-28 12:29:08,838 Tool did not define exit code or stdio handling; checking stderr for success galaxy.tools DEBUG 2013-01-28 12:29:09,135 Error opening galaxy.json file: [Errno 2] No such file or directory: '/home/rosema1/Projects/galaxy-dist/database/job_working_directory/000/418/galaxy.json' galaxy.jobs DEBUG 2013-01-28 12:29:09,439 job 418 ended galaxy.jobs DEBUG 2013-01-28 12:29:10,041 (420) Working directory for job is: /home/rosema1/Projects/galaxy-dist/database/job_working_directory/000/420 galaxy.jobs.handler DEBUG 2013-01-28 12:29:10,042 dispatching job 420 to local runner galaxy.jobs.handler INFO 2013-01-28 12:29:10,200 (420) Job dispatched galaxy.jobs.runners.local DEBUG 2013-01-28 12:29:10,385 Local runner: starting job 420 galaxy.jobs.runners.local DEBUG 2013-01-28 12:29:10,759 executing: python /home/rosema1/Projects/galaxy-dist/tools/fastq/fastq_filter.py /home/rosema1/Projects/galaxy-dist/database/files/000/dataset_592.dat /home/rosema1/Projects/galaxy-dist/database/job_working_directory/000/420/tmph0Ll2V /home/rosema1/Projects/galaxy-dist/database/files/000/dataset_594.dat /home/rosema1/Projects/galaxy-dist/database/job_working_directory/000/420/dataset_594_files 'sanger' 127.0.0.1 - - [28/Jan/2013:12:29:12 -0400] GET /api/histories/82b264d8c3d11790 HTTP/1.1 200 - http://127.0.0.1:8081/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 127.0.0.1 - - [28/Jan/2013:12:29:12 -0400] GET /api/users/f2db41e1fa331b3e HTTP/1.1 200 - http://127.0.0.1:8081/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 127.0.0.1 - - [28/Jan/2013:12:29:12 -0400] GET /api/histories/82b264d8c3d11790/contents?ids=3da459a26c8f00b4%2C736af8f0a76a2e71 HTTP/1.1 200 - http://127.0.0.1:8081/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 127.0.0.1 - - [28/Jan/2013:12:29:16 -0400] GET /api/histories/82b264d8c3d11790 HTTP/1.1 200 - http://127.0.0.1:8081/history; Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 Though I seem to see this even when a step completes and the workflow proceeds. Moreover, if I then begin executing the next steps in the workflow, they work, but create new entries in the history. So, some questions: Why is this happening and what can I do to get workflows to run to completion? Also, is it possible to reinitiate the workflow from the premature stopping point without having to launch each step individually and point each at new inputs rather than the ones dictated in the workflow? Thanks Mark This message may contain confidential information. If you are not the designated recipient, please notify the sender immediately, and delete the original and any copies. Any use of the message by you is prohibited. ___ 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/
[galaxy-dev] Pull request for bowtie_wrappers tool
Dear Galaxy DevTeam, I have made a few updates to the bowtie_wrappers tool from the Tool Shed, may someone please pull from: https://bitbucket.org/nsoranzo/bowtie_wrappers/ for the following changes: - Add fields for --nofw and --norc options also for single-end reads - Remove field for --cutoff option of bowtie-build - Do not show fields for --best and --strata options for paired-end reads - Add control to choose between -a and -k options - Show fields for --pairtries and --maxbts options only when noTryHard - Add control to choose between Maq- and SOAP-like alignment - Add range validators to all integer parameters I am not sure this mailing list is the correct place for such pull requests, if not please advise me! Thanks, Nicola -- Nicola Soranzo, Ph.D. CRS4 Bioinformatics Program Loc. Piscina Manna 09010 Pula (CA), Italy http://www.bioinformatica.crs4.it/ ___ 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/
Re: [galaxy-dev] Nice 'citable' URLs for Galaxy Tool Shed repositories
Hi Peter, Thanks for your request, having citable tool shed URLs is definitely important. I've got this on my list (which is maxed out as usual). I will look into this in a timely manner and keep you posted appropriately. Greg Von Kuster On Jan 28, 2013, at 8:41 AM, Peter Cock wrote: Dear all, Something I am conscious of every time I have directed someone to a tool or wrapper on the Galaxy Tool Shed is the lack of nice stable URLs. The current frame based design hinders this - and as a result I usually just have to give the ToolShed URL and tell them what to search for. This problem is particularly acute for citing a tool shed entry, where a nice URL would be far better. I appreciate moving away from the current frame interface is a lot of work - although what Jeremy Goecks wrote last week suggests that is a long term goal: http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-January/012792.html I would like something similar to the repository URL, but for the ToolShed interface. e.g. The repository view for my MIRA wrapper: http://toolshed.g2.bx.psu.edu/repos/peterjc/mira_assembler Perhaps is the short-term what could be done is to enhance the repository view, and include links between this and the current Tool Shed frame based page? That way we can share a nice URL like http://toolshed.g2.bx.psu.edu/repos/peterjc/mira_assembler to direct someone to a resource in the Tool Shed? e.g. (1) When viewing an entry on the Tool Shed, include a prominent link to the repository URL (perhaps even with social media links like tweet or share this to emphasise this is the best URL to share). (2) In the header for each repo (perhaps in place of the current Mercuiral logo?) have a link to the Tool Shed frameset for the tool being viewed. 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/ ___ 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/
Re: [galaxy-dev] Nice 'citable' URLs for Galaxy Tool Shed repositories
On Mon, Jan 28, 2013 at 6:49 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hi Peter, Thanks for your request, having citable tool shed URLs is definitely important. I've got this on my list (which is maxed out as usual). I will look into this in a timely manner and keep you posted appropriately. Greg Von Kuster Sounds like my to do list too :( Is there a Trello issue on this, or should I file one? Thanks, Peter P.S. Citable Tool Shed URLs would also be good for the @GalaxyProject tweets, as pointed out by John Chilton: https://twitter.com/jmchilton/status/295890843372515328 ___ 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/
Re: [galaxy-dev] History not updating automatically
Hi Brad and Sajoscha, Is there any chance that your proxy configurations are not passing the username in the REMOTE_USER header when the request is to an /api path? Could you provide the relevant portions of your proxy server configs? Thanks, --nate On Jan 28, 2013, at 7:12 AM, Langhorst, Brad wrote: Hi Sajoscha: I have exactly the same problem… it started about a month ago. Also with external ldap auth. I have not yet investigated in detail, since it's not crippling - just annoying. Brad On Jan 28, 2013, at 6:38 AM, Sajoscha Sauer sa...@embl.de wrote: Hi list, I have a weird problem after updating to the latest version. After doing the update as usual, the history panel is not updating automatically anymore. And when I press refresh, I get an javascript popup saying: Error getting history updates from the server. Forbidden Also, in the log I see the following: galaxy.web.framework WARNING 2013-01-28 12:30:01,673 User logged in as '(null)' externally, but has a cookie as 'sa...@embl.de' invalidating session We are using LDAP to connect to Galaxy, but I don't know if this has something to do with the problem. As I said, it was working perfectly fine before the update. Does someone know the problem or has any ideas? Thanks for your help, Sajoscha ___ 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/ -- Brad Langhorst langho...@neb.com ___ 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/ ___ 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/
Re: [galaxy-dev] Nice 'citable' URLs for Galaxy Tool Shed repositories
I've opened a Trello card, but it's in the Galaxy development project, so not sure if you can see it or not. Here's the link to the card just in case... https://trello.com/card/nice-citable-urls-for-galaxy-tool-shed-repositories/506338ce32ae458f6d15e4b3/182 On Jan 28, 2013, at 2:28 PM, Peter Cock wrote: On Mon, Jan 28, 2013 at 6:49 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hi Peter, Thanks for your request, having citable tool shed URLs is definitely important. I've got this on my list (which is maxed out as usual). I will look into this in a timely manner and keep you posted appropriately. Greg Von Kuster Sounds like my to do list too :( Is there a Trello issue on this, or should I file one? Thanks, Peter P.S. Citable Tool Shed URLs would also be good for the @GalaxyProject tweets, as pointed out by John Chilton: https://twitter.com/jmchilton/status/295890843372515328 ___ 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/
[galaxy-dev] Galaxy with EMBOSS 5 or EMBOSS 6 ?
Dear Galaxians, I am troubleshooting a problem with running EMBOSS infoseq on our local galaxy installation. We are running EMBOSS 6.5. There is a mismatch between the options Galaxy is passing to infoseq (-version), and what infoseq wants (-seqversion). This breaks the tool. While this would be easy to fix in this instance, I wonder if I should be using EMBOSS 5 (which is *really* old, mind you) instead of EMBOSS 6. I suspect with EMBOSS 6 there may be a whole host of similar changes to be made. Can anyone advise? If it turns out that EMBOSS 5 is actually required, perhaps someone could update the relevant info on the Galaxy dependencies page, or at least point me to the place where it says this. cheers, Simon Simon Guest Senior UNIX Technical Consultant AgResearch === Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. === ___ 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/
Re: [galaxy-dev] Galaxy with EMBOSS 5 or EMBOSS 6 ?
Hey Simon, You're right -- the EMBOSS version supported by the Galaxy wrappers is currently EMBOSS 5. We do have a Tool Dependency page here: http://wiki.galaxyproject.org/Admin/Tools/Tool%20Dependencies, but unfortunately while it lists versions for many tools it doesn't cover them all. I'll update the EMBOSS entry. As far as updating the galaxy EMBOSS wrappers to use a newer version, I'm not aware of any plans to do this currently (though someone could certainly do this if so inclined). -Dannon On Jan 28, 2013, at 3:10 PM, Guest, Simon simon.gu...@agresearch.co.nz wrote: Dear Galaxians, I am troubleshooting a problem with running EMBOSS infoseq on our local galaxy installation. We are running EMBOSS 6.5. There is a mismatch between the options Galaxy is passing to infoseq (-version), and what infoseq wants (-seqversion). This breaks the tool. While this would be easy to fix in this instance, I wonder if I should be using EMBOSS 5 (which is *really* old, mind you) instead of EMBOSS 6. I suspect with EMBOSS 6 there may be a whole host of similar changes to be made. Can anyone advise? If it turns out that EMBOSS 5 is actually required, perhaps someone could update the relevant info on the Galaxy dependencies page, or at least point me to the place where it says this. cheers, Simon Simon Guest Senior UNIX Technical Consultant AgResearch === Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. === ___ 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/ ___ 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/
Re: [galaxy-dev] Galaxy with EMBOSS 5 or EMBOSS 6 ?
You're right -- the EMBOSS version supported by the Galaxy wrappers is currently EMBOSS 5. We do have a Tool Dependency page here: http://wiki.galaxyproject.org/Admin/Tools/Tool%20Dependencies, but unfortunately while it lists versions for many tools it doesn't cover them all. I'll update the EMBOSS entry. Hi Dannon, Thanks. After a bit more looking around, I also found the version in the tool_conf.xml file, which confirmed I need to install EMBOSS 5.0.0. As far as updating the galaxy EMBOSS wrappers to use a newer version, I'm not aware of any plans to do this currently (though someone could certainly do this if so inclined). We may do this ourselves, and contribute the updates. First we'll get it all rolled out with EMBOSS 5. Later on I may be back in touch about how we can contribute updates into the Galaxy mainline. cheers, Simon === Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. === ___ 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/
Re: [galaxy-dev] error uploading file with fresh installation: this request returned None from get_history()
I was incorrect in stating that the changes in the next galaxy-dist will
help in this case, unfortunately. From the stack trace you posted, there is
a deeper error with your instance that the client-side changes won't help.
Can you post the size, type, and name of the file you're trying to upload?
On Thu, Jan 24, 2013 at 6:12 PM, Dan Tenenbaum dtene...@fhcrc.org wrote:
On Wed, Jan 23, 2013 at 3:19 PM, Carl Eberhard carlfeberh...@gmail.com
wrote:
Another thing you might try is to upload the file to our test server:
https://test.g2.bx.psu.edu/ and see if that works.
Thanks, that does work.
Setting up an FTP server on my local installation seems pretty
complex. All I really want to do is work around this issue and fool
Galaxy into thinking that I have uploaded a file using the
uploader...since this is a local installation I can put a file
anywhere on my system, I don't have to actually upload it, just place
it in a directory.
If there is no such workaround, I'll wait for the fix, I guess. Thanks
very much for working on this!
Dan
On Wed, Jan 23, 2013 at 6:06 PM, Carl Eberhard carlfeberh...@gmail.com
wrote:
If this is happening consistently and a refresh on the history isn't
doing
anything, you might try ftp upload:
http://wiki.galaxyproject.org/FTPUpload
or if you have permissions or are an admin you can try uploading to a
data
library:
http://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles
On Wed, Jan 23, 2013 at 5:44 PM, Dan Tenenbaum dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 2:42 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
What sort of database are you using on your local instance?
The default (sqlite I guess). It's a completely vanilla instance, I
have not touched the config files.
Dan
On Wed, Jan 23, 2013 at 5:37 PM, Dan Tenenbaum dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 2:35 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Thanks, Dan. That helps and I'll start looking into this.
We will be pushing out a new galaxy-dist revision sometime this
week
if
all
goes well. This revision includes some code for the history panel
that
may
help handle this situation a bit better. I'd recommend updating to
that
revision when it comes out.
Thanks! Is there a workaround to upload a file or add it to my
history
in the meantime? Command-line is ok. If there isn't one, that's ok
too
Dan
I'll let you know what I can find.
Carl
On Wed, Jan 23, 2013 at 5:18 PM, Dan Tenenbaum
dtene...@fhcrc.org
wrote:
Hi Carl,
On Wed, Jan 23, 2013 at 2:14 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Heya, Dan.
Sorry for the trouble.
When you get that error again look for a line like you have
above:
Debug at: http://localhost:8080/_debug/view/1358978130
If you open a new tab or window in your browser and go to the
address
('http://localhost:8080/_debug ...'), you should see a more
informative
error message - complete with a list of function calls that led
to
the
error
(a stack trace).
Can you post that stack trace when you see it?
Thanks for the quick response. Here it is:
URL: http://localhost:8080/tool_runner/upload_async_create
File
'/Users/dtenenba/dev/galaxy-dist/eggs/WebError-0.8a-py2.7.egg/weberror/evalexception/middleware.py',
line 364 in respond
app_iter = self.application(environ, detect_start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/debug/prints.py',
line 98 in __call__
environ, self.app)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/wsgilib.py',
line 539 in intercept_output
app_iter = application(environ, replacement_start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/recursive.py',
line 80 in __call__
return self.application(environ, start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/httpexceptions.py',
line 632 in __call__
return self.application(environ, start_response)
File
'/Users/dtenenba/dev/galaxy-dist/lib/galaxy/web/framework/base.py',
line 160 in __call__
body = method( trans, **kwargs )
File
'/Users/dtenenba/dev/galaxy-dist/lib/galaxy/web/framework/__init__.py',
line 73 in decorator
return simplejson.dumps( func( self, trans, *args, **kwargs ) )
File
'/Users/dtenenba/dev/galaxy-dist/lib/galaxy/webapps/galaxy/controllers/tool_runner.py',
line 317 in upload_async_create
datasets.append( create_dataset( name ) )
File
Re: [galaxy-dev] error uploading file with fresh installation: this request returned None from get_history()
On Mon, Jan 28, 2013 at 1:40 PM, Carl Eberhard carlfeberh...@gmail.com wrote:
I was incorrect in stating that the changes in the next galaxy-dist will
help in this case, unfortunately. From the stack trace you posted, there is
a deeper error with your instance that the client-side changes won't help.
Can you post the size, type, and name of the file you're trying to upload?
I can reproduce this by just typing hello, world into the
URL/Text: box on the Upload File page. Any file of any type seems
to trigger this problem.
Thanks,
Dan
On Thu, Jan 24, 2013 at 6:12 PM, Dan Tenenbaum dtene...@fhcrc.org wrote:
On Wed, Jan 23, 2013 at 3:19 PM, Carl Eberhard carlfeberh...@gmail.com
wrote:
Another thing you might try is to upload the file to our test server:
https://test.g2.bx.psu.edu/ and see if that works.
Thanks, that does work.
Setting up an FTP server on my local installation seems pretty
complex. All I really want to do is work around this issue and fool
Galaxy into thinking that I have uploaded a file using the
uploader...since this is a local installation I can put a file
anywhere on my system, I don't have to actually upload it, just place
it in a directory.
If there is no such workaround, I'll wait for the fix, I guess. Thanks
very much for working on this!
Dan
On Wed, Jan 23, 2013 at 6:06 PM, Carl Eberhard carlfeberh...@gmail.com
wrote:
If this is happening consistently and a refresh on the history isn't
doing
anything, you might try ftp upload:
http://wiki.galaxyproject.org/FTPUpload
or if you have permissions or are an admin you can try uploading to a
data
library:
http://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles
On Wed, Jan 23, 2013 at 5:44 PM, Dan Tenenbaum dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 2:42 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
What sort of database are you using on your local instance?
The default (sqlite I guess). It's a completely vanilla instance, I
have not touched the config files.
Dan
On Wed, Jan 23, 2013 at 5:37 PM, Dan Tenenbaum dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 2:35 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Thanks, Dan. That helps and I'll start looking into this.
We will be pushing out a new galaxy-dist revision sometime this
week
if
all
goes well. This revision includes some code for the history panel
that
may
help handle this situation a bit better. I'd recommend updating
to
that
revision when it comes out.
Thanks! Is there a workaround to upload a file or add it to my
history
in the meantime? Command-line is ok. If there isn't one, that's ok
too
Dan
I'll let you know what I can find.
Carl
On Wed, Jan 23, 2013 at 5:18 PM, Dan Tenenbaum
dtene...@fhcrc.org
wrote:
Hi Carl,
On Wed, Jan 23, 2013 at 2:14 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Heya, Dan.
Sorry for the trouble.
When you get that error again look for a line like you have
above:
Debug at: http://localhost:8080/_debug/view/1358978130
If you open a new tab or window in your browser and go to the
address
('http://localhost:8080/_debug ...'), you should see a more
informative
error message - complete with a list of function calls that
led
to
the
error
(a stack trace).
Can you post that stack trace when you see it?
Thanks for the quick response. Here it is:
URL: http://localhost:8080/tool_runner/upload_async_create
File
'/Users/dtenenba/dev/galaxy-dist/eggs/WebError-0.8a-py2.7.egg/weberror/evalexception/middleware.py',
line 364 in respond
app_iter = self.application(environ, detect_start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/debug/prints.py',
line 98 in __call__
environ, self.app)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/wsgilib.py',
line 539 in intercept_output
app_iter = application(environ, replacement_start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/recursive.py',
line 80 in __call__
return self.application(environ, start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/httpexceptions.py',
line 632 in __call__
return self.application(environ, start_response)
File
'/Users/dtenenba/dev/galaxy-dist/lib/galaxy/web/framework/base.py',
line 160 in __call__
body = method( trans, **kwargs )
File
'/Users/dtenenba/dev/galaxy-dist/lib/galaxy/web/framework/__init__.py',
line 73 in decorator
return simplejson.dumps( func( self, trans, *args, **kwargs )
)
Re: [galaxy-dev] error uploading file with fresh installation: this request returned None from get_history()
If you go to your galaxy root in a terminal and then cd to eggs, what is
the version listed for SQLAlchemy?
Do you have SQLAlchemy installed already on that machine (apart from the
one in Galaxy's eggs)?
On Mon, Jan 28, 2013 at 4:50 PM, Dan Tenenbaum dtene...@fhcrc.org wrote:
On Mon, Jan 28, 2013 at 1:40 PM, Carl Eberhard carlfeberh...@gmail.com
wrote:
I was incorrect in stating that the changes in the next galaxy-dist will
help in this case, unfortunately. From the stack trace you posted, there
is
a deeper error with your instance that the client-side changes won't
help.
Can you post the size, type, and name of the file you're trying to
upload?
I can reproduce this by just typing hello, world into the
URL/Text: box on the Upload File page. Any file of any type seems
to trigger this problem.
Thanks,
Dan
On Thu, Jan 24, 2013 at 6:12 PM, Dan Tenenbaum dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 3:19 PM, Carl Eberhard carlfeberh...@gmail.com
wrote:
Another thing you might try is to upload the file to our test server:
https://test.g2.bx.psu.edu/ and see if that works.
Thanks, that does work.
Setting up an FTP server on my local installation seems pretty
complex. All I really want to do is work around this issue and fool
Galaxy into thinking that I have uploaded a file using the
uploader...since this is a local installation I can put a file
anywhere on my system, I don't have to actually upload it, just place
it in a directory.
If there is no such workaround, I'll wait for the fix, I guess. Thanks
very much for working on this!
Dan
On Wed, Jan 23, 2013 at 6:06 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
If this is happening consistently and a refresh on the history isn't
doing
anything, you might try ftp upload:
http://wiki.galaxyproject.org/FTPUpload
or if you have permissions or are an admin you can try uploading to a
data
library:
http://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles
On Wed, Jan 23, 2013 at 5:44 PM, Dan Tenenbaum dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 2:42 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
What sort of database are you using on your local instance?
The default (sqlite I guess). It's a completely vanilla instance, I
have not touched the config files.
Dan
On Wed, Jan 23, 2013 at 5:37 PM, Dan Tenenbaum
dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 2:35 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Thanks, Dan. That helps and I'll start looking into this.
We will be pushing out a new galaxy-dist revision sometime this
week
if
all
goes well. This revision includes some code for the history
panel
that
may
help handle this situation a bit better. I'd recommend updating
to
that
revision when it comes out.
Thanks! Is there a workaround to upload a file or add it to my
history
in the meantime? Command-line is ok. If there isn't one, that's
ok
too
Dan
I'll let you know what I can find.
Carl
On Wed, Jan 23, 2013 at 5:18 PM, Dan Tenenbaum
dtene...@fhcrc.org
wrote:
Hi Carl,
On Wed, Jan 23, 2013 at 2:14 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Heya, Dan.
Sorry for the trouble.
When you get that error again look for a line like you have
above:
Debug at: http://localhost:8080/_debug/view/1358978130
If you open a new tab or window in your browser and go to
the
address
('http://localhost:8080/_debug ...'), you should see a more
informative
error message - complete with a list of function calls that
led
to
the
error
(a stack trace).
Can you post that stack trace when you see it?
Thanks for the quick response. Here it is:
URL: http://localhost:8080/tool_runner/upload_async_create
File
'/Users/dtenenba/dev/galaxy-dist/eggs/WebError-0.8a-py2.7.egg/weberror/evalexception/middleware.py',
line 364 in respond
app_iter = self.application(environ, detect_start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/debug/prints.py',
line 98 in __call__
environ, self.app)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/wsgilib.py',
line 539 in intercept_output
app_iter = application(environ, replacement_start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/recursive.py',
line 80 in __call__
return self.application(environ, start_response)
File
Re: [galaxy-dev] error uploading file with fresh installation: this request returned None from get_history()
On Mon, Jan 28, 2013 at 1:59 PM, Carl Eberhard carlfeberh...@gmail.com wrote:
If you go to your galaxy root in a terminal and then cd to eggs, what is the
version listed for SQLAlchemy?
SQLAlchemy-0.5.6_dev_r6498-py2.7.egg
Do you have SQLAlchemy installed already on that machine (apart from the one
in Galaxy's eggs)?
I don't think so. I never knowingly installed it and in a fresh python
session, 'import sqlalchemy' returns an error that there is no such
module.
Thanks,
Dan
On Mon, Jan 28, 2013 at 4:50 PM, Dan Tenenbaum dtene...@fhcrc.org wrote:
On Mon, Jan 28, 2013 at 1:40 PM, Carl Eberhard carlfeberh...@gmail.com
wrote:
I was incorrect in stating that the changes in the next galaxy-dist will
help in this case, unfortunately. From the stack trace you posted, there
is
a deeper error with your instance that the client-side changes won't
help.
Can you post the size, type, and name of the file you're trying to
upload?
I can reproduce this by just typing hello, world into the
URL/Text: box on the Upload File page. Any file of any type seems
to trigger this problem.
Thanks,
Dan
On Thu, Jan 24, 2013 at 6:12 PM, Dan Tenenbaum dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 3:19 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Another thing you might try is to upload the file to our test server:
https://test.g2.bx.psu.edu/ and see if that works.
Thanks, that does work.
Setting up an FTP server on my local installation seems pretty
complex. All I really want to do is work around this issue and fool
Galaxy into thinking that I have uploaded a file using the
uploader...since this is a local installation I can put a file
anywhere on my system, I don't have to actually upload it, just place
it in a directory.
If there is no such workaround, I'll wait for the fix, I guess. Thanks
very much for working on this!
Dan
On Wed, Jan 23, 2013 at 6:06 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
If this is happening consistently and a refresh on the history isn't
doing
anything, you might try ftp upload:
http://wiki.galaxyproject.org/FTPUpload
or if you have permissions or are an admin you can try uploading to
a
data
library:
http://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles
On Wed, Jan 23, 2013 at 5:44 PM, Dan Tenenbaum dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 2:42 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
What sort of database are you using on your local instance?
The default (sqlite I guess). It's a completely vanilla instance, I
have not touched the config files.
Dan
On Wed, Jan 23, 2013 at 5:37 PM, Dan Tenenbaum
dtene...@fhcrc.org
wrote:
On Wed, Jan 23, 2013 at 2:35 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Thanks, Dan. That helps and I'll start looking into this.
We will be pushing out a new galaxy-dist revision sometime
this
week
if
all
goes well. This revision includes some code for the history
panel
that
may
help handle this situation a bit better. I'd recommend
updating
to
that
revision when it comes out.
Thanks! Is there a workaround to upload a file or add it to my
history
in the meantime? Command-line is ok. If there isn't one, that's
ok
too
Dan
I'll let you know what I can find.
Carl
On Wed, Jan 23, 2013 at 5:18 PM, Dan Tenenbaum
dtene...@fhcrc.org
wrote:
Hi Carl,
On Wed, Jan 23, 2013 at 2:14 PM, Carl Eberhard
carlfeberh...@gmail.com
wrote:
Heya, Dan.
Sorry for the trouble.
When you get that error again look for a line like you have
above:
Debug at: http://localhost:8080/_debug/view/1358978130
If you open a new tab or window in your browser and go to
the
address
('http://localhost:8080/_debug ...'), you should see a more
informative
error message - complete with a list of function calls that
led
to
the
error
(a stack trace).
Can you post that stack trace when you see it?
Thanks for the quick response. Here it is:
URL: http://localhost:8080/tool_runner/upload_async_create
File
'/Users/dtenenba/dev/galaxy-dist/eggs/WebError-0.8a-py2.7.egg/weberror/evalexception/middleware.py',
line 364 in respond
app_iter = self.application(environ, detect_start_response)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/debug/prints.py',
line 98 in __call__
environ, self.app)
File
'/Users/dtenenba/dev/galaxy-dist/eggs/Paste-1.6-py2.7.egg/paste/wsgilib.py',
line 539 in intercept_output
[galaxy-dev] Tool shed and tools with dynamically generated select list parameters
Hi, I'm trying to get lastz to show a locally cached reference. As I'm used to do I went ahead and copy tool-data/lastz_seqs.loc.sample(still included with galaxy-dist) to tool-data/lastz_seqs.loc and added my local references. Nothing happened. I get: galaxy.tools.parameters.dynamic_options WARNING 2013-01-28 16:42:58,203 Data table named 'lastz_seqs' is required by tool but not configured I realized there are these two files in the lastz repository: ../shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/lastz/0801f8207d30/lastz/tool_data_table_conf.xml.sample ../shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/lastz/0801f8207d30/lastz/tool-data/lastz_seqs.loc.sample I created their minus '.sample' versions in the same locations and added my local references to this lastz_seqs.loc, still nothing. I finally manually edited the main tool_data_table_conf.xml adding: !-- Locations of 2bit sequence files for use in Lastz -- table name=lastz_seqs comment_char=# columnsvalue, name, path/columns file path=tool-data/lastz_seqs.loc / /table And that did the trick. Is this the expected way of handling these cases?. This paragraph from the wiki didn't clarify much for me: http://wiki.galaxyproject.org/InstallingRepositoriesToGalaxy Tool shed repositories that contain tools that include dynamically generated select list parameters that refer to an entry in the tool_data_table_conf.xml file must contain a tool_data_table_conf.xml.sample file that contains the required entry for each dynamic parameter. Similarly, any index files (i.e., ~/tool-data/xxx.loc files) to which the tool_data_table_conf.xml file entries refer must be defined in xxx.loc.sample files included in the tool shed repository along with the tools. If any of these tool_data_table_conf.xml entries or any of the required xxx.loc.sample files are missing from the tool shed repository, the tools will not properly load and metadata will not be generated for the repository. This means that the tools cannot be automatically installed into a Galaxy instance. Best regards, Carlos ___ 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/
Re: [galaxy-dev] Tool shed and tools with dynamically generated select list parameters
Hello Carlos, On Jan 28, 2013, at 5:13 PM, Carlos Borroto wrote: Hi, I'm trying to get lastz to show a locally cached reference. As I'm used to do I went ahead and copy tool-data/lastz_seqs.loc.sample(still included with galaxy-dist) to tool-data/lastz_seqs.loc and added my local references. Nothing happened. I get: galaxy.tools.parameters.dynamic_options WARNING 2013-01-28 16:42:58,203 Data table named 'lastz_seqs' is required by tool but not configured I realized there are these two files in the lastz repository: ../shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/lastz/0801f8207d30/lastz/tool_data_table_conf.xml.sample ../shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/lastz/0801f8207d30/lastz/tool-data/lastz_seqs.loc.sample I created their minus '.sample' versions in the same locations and added my local references to this lastz_seqs.loc, still nothing. I finally manually edited the main tool_data_table_conf.xml adding: !-- Locations of 2bit sequence files for use in Lastz -- table name=lastz_seqs comment_char=# columnsvalue, name, path/columns file path=tool-data/lastz_seqs.loc / /table And that did the trick. Is this the expected way of handling these cases?. Yes, however, if your install the repository from the Galaxy administrator interface, this should all happen automatically for you. If you download the repository as a tar archive and manually install it from outside of the Galaxy interface, you'll have to do all of this manually. This paragraph from the wiki didn't clarify much for me: http://wiki.galaxyproject.org/InstallingRepositoriesToGalaxy Tool shed repositories that contain tools that include dynamically generated select list parameters that refer to an entry in the tool_data_table_conf.xml file must contain a tool_data_table_conf.xml.sample file that contains the required entry for each dynamic parameter. Similarly, any index files (i.e., ~/tool-data/xxx.loc files) to which the tool_data_table_conf.xml file entries refer must be defined in xxx.loc.sample files included in the tool shed repository along with the tools. If any of these tool_data_table_conf.xml entries or any of the required xxx.loc.sample files are missing from the tool shed repository, the tools will not properly load and metadata will not be generated for the repository. This means that the tools cannot be automatically installed into a The next paragraph in the same wiki page clarifies this: For those tools that include dynamically generated select list parameters that require a missing entry in the tool_data_table_conf.xml file, this file will be modified in real time by adding the entry from a tool_data_table_conf.xml.sample file contained in the tool shed repository. Galaxy instance. Best regards, Carlos ___ 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/ ___ 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/
Re: [galaxy-dev] Tool shed and tools with dynamically generated select list parameters
On Mon, Jan 28, 2013 at 5:29 PM, Greg Von Kuster g...@bx.psu.edu wrote: And that did the trick. Is this the expected way of handling these cases?. Yes, however, if your install the repository from the Galaxy administrator interface, this should all happen automatically for you. If you download the repository as a tar archive and manually install it from outside of the Galaxy interface, you'll have to do all of this manually. I guess I overwrote the main tool_data_table_conf.xml with the sample one at some point, cause I don't remember installing this repository manually. The next paragraph in the same wiki page clarifies this: For those tools that include dynamically generated select list parameters that require a missing entry in the tool_data_table_conf.xml file, this file will be modified in real time by adding the entry from a tool_data_table_conf.xml.sample file contained in the tool shed repository. Ooops, I stopped reading too soon. Thanks, Carlos ___ 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/
Re: [galaxy-dev] Loading a library of bam files
It looks like if I set 'retry_metadata_internally = False' it stops trying to index them on the queue node. The datasets get added into the library, without a BAM index file, but without error. I guess the index files can be generated on demand later on. Kyle On Mon, Jan 28, 2013 at 12:42 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hi Kyle, I'm hoping I can help you a bit on this, although i am not very familiar with the code that is producing this behavior. Your previous reply mentions the following: During job cleanup, galaxy.jobs.__init__.py:412, because external_metadata_set_successfully returns false. An external set_metadata.sh job was run, but it doesn't seem to call samtools. Maybe if I figure out why set_metadata.sh isn't working, this problem will go away. Based on your comments, there are a few things you can do: 1. If setting external metadata results in an error, the error should be printed out in your paster log. Do you see anything relevant there? 2. You also may be able to discover the error if you perform the following sql manually - make sure your have the correct job_id: select filename_results_code from job_external_output_metadata where job_id = job_id; 3. Make sure you have the following config setting uncommented and set to False in your universe_wsgi.ini (the default is set to True): # Although it is fairly reliable, setting metadata can occasionally fail. In # these instances, you can choose to retry setting it internally or leave it in # a failed state (since retrying internally may cause the Galaxy process to be # unresponsive). If this option is set to False, the user will be given the # option to retry externally, or set metadata manually (when possible). retry_metadata_internally = False Let me know if any of this helps you resolve the problem, and if not, we'll figure out next steps if possible. Thanks, Greg Von Kuster On Jan 24, 2013, at 4:36 PM, Kyle Ellrott wrote: I'm willing to put in the coding time, but I'd need some pointers on the best way to go about making the changes. Kyle On Wed, Jan 23, 2013 at 6:35 PM, Anthonius deBoer thondeb...@me.comwrote: I also second this request to get it addressed (Where can we vote on bug fixes ?! :) ...It is very weird that samtools is run on the local machine and it even does the indexing sequentially... Thon On Jan 23, 2013, at 03:28 PM, Kyle Ellrott kellr...@soe.ucsc.edu wrote: I'm currently in the process of loading (path paste) a large library of BAM files (1) into the shared Data Libraries of our local galaxy installation, but I'm finding this process to be very slow. I'm doing a path paste, and not actually copying the files. I have disabled local running of 'upload1', so that it will run on the cluster, and set 'set_metadata_externally' to true. It looks like the job handlers are calling 'samtools index' directly. Looking through the code, that seems to happen in galaxy/datatypes/binary in Bam.dataset_content_needs_grooming, where it calls 'samtools index' and then waits. What would be the most efficient way to start changing the code so that this process can be done by an external script, at a deferred time out on the cluster? Kyle ___ 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/ ___ 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/ ___ 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/
