[galaxy-dev] Bug in history when using Admin account ??
Hi, I believe I have found a bug? Or maybe I'm not using Galaxy correctly? These are the steps I used: * Downloaded the latest version of Galaxy * Created a user m...@me.commailto:m...@me.com * Uploaded several files * Logged out * Create a user y...@you.commailto:y...@you.com * Uploaded several files * Logged out and then logged in as an Admin user (specified in universe_wsgi.ini file) * Uploaded a file. Now when I log into m...@me.commailto:m...@me.com or y...@you.commailto:y...@you.com the history shows only the uploaded file that I uploaded as an Admin. Even logging in as Admin and using the impersonate feature doesn't allow me to view the history of m...@me.commailto:m...@me.com or y...@you.commailto:y...@you.com. The files still exist as I can see them in database/files/000 Is this a bug? Or are Admins not supposed to upload files? Also I tried: * Deleted the above galaxy-dist * Downloaded the latest version of Galaxy * Created a user m...@me.commailto:m...@me.com * Uploaded several files * Logged out * Create a user y...@you.commailto:y...@you.com * Uploaded several files * Logged out and then logged in as an Admin user (specified in universe_wsgi.ini file) * Didn't upload a file * Logged out of Admin Now when I log into m...@me.commailto:m...@me.com or y...@you.commailto:y...@you.com the history is empty. This can't be correct is it? 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/
Re: [galaxy-dev] Bug in history when using Admin account ??
Hi Neil Just double checking: Have you looked at the list of 'Saved Histories'? For each user, you probably have several histories called 'Unnamed history' and one of them may contain the data you uploaded previously. Whenever you log out and log in as a different user, a new, empty history called 'Unnamed history' is created. Regards, Hans-Rudolf On 05/17/2013 08:04 AM, neil.burd...@csiro.au wrote: Hi, I believe I have found a bug? Or maybe I’m not using Galaxy correctly? These are the steps I used: ·Downloaded the latest version of Galaxy ·Created a user m...@me.com mailto:m...@me.com ·Uploaded several files ·Logged out ·Create a user y...@you.com mailto:y...@you.com ·Uploaded several files ·Logged out and then logged in as an Admin user (specified in universe_wsgi.ini file) ·Uploaded a file. Now when I log into m...@me.com mailto:m...@me.com or y...@you.com mailto:y...@you.com the history shows only the uploaded file that I uploaded as an Admin. Even logging in as Admin and using the “impersonate” feature doesn’t allow me to view the history of m...@me.com mailto:m...@me.com or y...@you.com mailto:y...@you.com. The files still exist as I can see them in database/files/000 Is this a bug? Or are Admins not supposed to upload files? Also I tried: ·Deleted the above galaxy-dist ·Downloaded the latest version of Galaxy ·Created a user m...@me.com mailto:m...@me.com ·Uploaded several files ·Logged out ·Create a user y...@you.com mailto:y...@you.com ·Uploaded several files ·Logged out and then logged in as an Admin user (specified in universe_wsgi.ini file) ·Didn’t upload a file ·Logged out of Admin Now when I log into m...@me.com mailto:m...@me.com or y...@you.com mailto:y...@you.com the history is empty. This can’t be correct is it? 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] Bug in history when using Admin account ??
Hans, You are correct. When I look at the Save Histories and I double click on them I can see everything. Thanks for the help Neil -Original Message- From: Hans-Rudolf Hotz [mailto:h...@fmi.ch] Sent: Friday, 17 May 2013 4:58 PM To: Burdett, Neil (ICT Centre, Herston - RBWH) Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Bug in history when using Admin account ?? Hi Neil Just double checking: Have you looked at the list of 'Saved Histories'? For each user, you probably have several histories called 'Unnamed history' and one of them may contain the data you uploaded previously. Whenever you log out and log in as a different user, a new, empty history called 'Unnamed history' is created. Regards, Hans-Rudolf On 05/17/2013 08:04 AM, neil.burd...@csiro.au wrote: Hi, I believe I have found a bug? Or maybe I'm not using Galaxy correctly? These are the steps I used: *Downloaded the latest version of Galaxy *Created a user m...@me.com mailto:m...@me.com *Uploaded several files *Logged out *Create a user y...@you.com mailto:y...@you.com *Uploaded several files *Logged out and then logged in as an Admin user (specified in universe_wsgi.ini file) *Uploaded a file. Now when I log into m...@me.com mailto:m...@me.com or y...@you.com mailto:y...@you.com the history shows only the uploaded file that I uploaded as an Admin. Even logging in as Admin and using the impersonate feature doesn't allow me to view the history of m...@me.com mailto:m...@me.com or y...@you.com mailto:y...@you.com. The files still exist as I can see them in database/files/000 Is this a bug? Or are Admins not supposed to upload files? Also I tried: *Deleted the above galaxy-dist *Downloaded the latest version of Galaxy *Created a user m...@me.com mailto:m...@me.com *Uploaded several files *Logged out *Create a user y...@you.com mailto:y...@you.com *Uploaded several files *Logged out and then logged in as an Admin user (specified in universe_wsgi.ini file) *Didn't upload a file *Logged out of Admin Now when I log into m...@me.com mailto:m...@me.com or y...@you.com mailto:y...@you.com the history is empty. This can't be correct is it? 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] selecting multiple inputs for workflows not possible anymore
Allright. I just pulled in all changesets from stable to my cloud Galaxy, restarted, and everything works, at first glance. Thanks for your support! J Joachim Jacob Rijvisschestraat 120, 9052 Zwijnaarde Tel: +32 9 244.66.34 Bioinformatics Training and Services (BITS) http://www.bits.vib.be @bitsatvib On 05/16/2013 05:21 PM, Dannon Baker wrote: Sorry, what I was saying was that you *can* pull these changes without leaving stable using 'hg pull -b stable http://bitbucket.org/galaxy/galaxy-central'. (Actually, if you're already on stable the -b is unnecessary -- you'll get the extra changesets but they won't be activated when you update) On Thu, May 16, 2013 at 11:08 AM, Joachim Jacob | VIB | joachim.ja...@vib.be mailto:joachim.ja...@vib.be wrote: OK. So I believe I can wait for the next stable release then. I assume a do not want to go the default branch. thanks, Joachim Joachim Jacob Rijvisschestraat 120, 9052 Zwijnaarde Tel: +32 9 244.66.34 tel:%2B32%209%20244.66.34 Bioinformatics Training and Services (BITS) http://www.bits.vib.be @bitsatvib On 05/16/2013 05:01 PM, Dannon Baker wrote: Your instance isn't quite up-to-date enough for the fix -- it's around 9549:47ddf167c9f1 -central / 9452:94caae7433a7 grafted in -stable. On Thu, May 16, 2013 at 10:56 AM, Joachim Jacob | VIB | joachim.ja...@vib.be mailto:joachim.ja...@vib.be mailto:joachim.ja...@vib.be mailto:joachim.ja...@vib.be wrote: Running the Cloud Galaxy: galaxy@ip-10-39-130-141:/mnt/galaxyTools/galaxy-central$ hg summary parent: 9232:75f09617abaa release_2013.04.01 Merge next-stable to stable for release. branch: stable commit: 2 modified, 9 unknown (new branch head) update: 30 new changesets (update) galaxy@ip-10-39-130-141:/mnt/galaxyTools/galaxy-central$ hg branch stable Our production Galaxy: [galaxy@galaxy galaxy-dist]$ hg summary parent: 9292:2cc8d10988e0 security_2013.04.08 controllers/history: use get_history in switch_to_history branch: stable commit: 4 modified, 267 unknown (new branch head) update: 11 new changesets (update) [galaxy@galaxy galaxy-dist]$ hg branch stable Joachim Jacob Rijvisschestraat 120, 9052 Zwijnaarde Tel: +32 9 244.66.34 tel:%2B32%209%20244.66.34 tel:%2B32%209%20244.66.34 Bioinformatics Training and Services (BITS) http://www.bits.vib.be @bitsatvib On 05/16/2013 04:35 PM, Dannon Baker wrote: I should have read the rest of my email before replying -- so you did update Galaxy for your cloud instance. What exact revision/branch are you running now? There was a brief period when select2 was enabled for the workflow page and it broke things. This should be fixed in -stable (and, of course, tip of -central). On Thu, May 16, 2013 at 10:12 AM, Joachim Jacob | VIB | joachim.ja...@vib.be mailto:joachim.ja...@vib.be mailto:joachim.ja...@vib.be mailto:joachim.ja...@vib.be mailto:joachim.ja...@vib.be mailto:joachim.ja...@vib.be mailto:joachim.ja...@vib.be mailto:joachim.ja...@vib.be wrote: Hi all, I just found out that I cannot select multiple inputs in workflows anymore in our local Galaxy. This option used to work on these workflows in the past. I only get now a dropdown box, without the little icon at the top of the input list to select multiple inputs. I am a little puzzled of what's wrong. Any light in the dark? I have repeated these steps in a freshly started cloud galaxy instance, updated to the latest release, and imported that workflow. In that instance, I can select multiple files: but it is not anymore with the multiple selection, but in a 'dropdown-checkbox-list' (hope this is clear). The problem is here that only one input gets processed, even the input list contains multiple items. Every item that is checked gets into the inputbox. A second issue is that this entry (already in the input list) is not removed from the checkbox-list: so you can select
[galaxy-dev] Workflow: multiple input errors
Hi all, I have fired up an cloud instance of Galaxy, 2 persistent nodes, scalable up to 10. I have updated the code to the latest stable, after issues with not being able to select multiple input for workflows (more background: http://dev.list.galaxyproject.org/selecting-multiple-inputs-for-workflows-not-possible-anymore-td4659827.html) Running a workflow on multiple inputs (#=58) gives me - after a very long page loading - this error: Internal Server Error Galaxy was unable to sucessfully complete your request URL: http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910 Module galaxy.web.framework.middleware.error:*149* in |__call__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#app_iter *=* self*.*application*(*environ*,* sr_checker*)*| Module paste.recursive:*84* in |__call__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* self*.*application*(*environ*,* start_response*)*| Module paste.httpexceptions:*633* in |__call__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* self*.*application*(*environ*,* start_response*)*| Module galaxy.web.framework.base:*128* in |__call__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* self*.*handle_request*(* environ*,* start_response *)*| Module galaxy.web.framework.base:*184* in |handle_request| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#body *=* method*(* trans*,* kwargs *)*| Module galaxy.webapps.galaxy.controllers.workflow:*1443* in |run| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#job*,* out_data *=* tool*.*execute*(* trans*,* step*.*state*.*inputs*,* history*=*target_history*)*| Module galaxy.tools:*2342* in |execute| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* self*.*tool_action*.*execute*(* self*,* trans*,* incoming*=*incoming*,* set_output_hid*=*set_output_hid*,* history*=*history*,* kwargs *)*| Module galaxy.tools.actions:*397* in |execute| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#job*.*add_input_dataset*(* name*,* dataset *)*| Module galaxy.model:*247* in |add_input_dataset| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*input_datasets*.*append*(* JobToInputDatasetAssociation*(* name*,* dataset *)* *)*| Module ?:*4* in |__init__| Module sqlalchemy.orm.state:*82* in |initialize_instance| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* manager*.*events*.*original_init*(mixed*[**1**:**]**,* kwargs*)*| Module galaxy.model:*450* in |__init__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*dataset *=* dataset| Module sqlalchemy.orm.attributes:*150* in |__set__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*impl*.*set*(*instance_state*(*instance*)**,* instance_dict*(*instance*)**,* value*,* None*)*| Module sqlalchemy.orm.attributes:*590* in |set| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#value *=* self*.*fire_replace_event*(*state*,* dict_*,* value*,* old*,* initiator*)*| Module sqlalchemy.orm.attributes:*610* in |fire_replace_event| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#value *=* ext*.*set*(*state*,* value*,* previous*,* initiator *or* self*)*| Module sqlalchemy.orm.unitofwork:*69* in |set| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#sess*.*add*(*newvalue*)*| Module sqlalchemy.orm.session:*1091* in |add| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*_save_or_update_state*(*state*)*| Module sqlalchemy.orm.session:*1100* in |_save_or_update_state| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*_save_or_update_impl*(*state*)*| Module sqlalchemy.orm.session:*1267* in |_save_or_update_impl| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*_update_impl*(*state*)*| Module sqlalchemy.orm.session:*1259* in |_update_impl| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*_attach*(*state*)*| Module sqlalchemy.orm.session:*1286* in |_attach| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*(*mapperutil*.*state_str*(*state*)**,* state*.*key*)*| *InvalidRequestError: Can't attach instance HistoryDatasetAssociation at 0x8591c50; another instance with key (class 'galaxy.model.HistoryDatasetAssociation', (200,)) is already present in this session.* extra
Re: [galaxy-dev] Handling of tool_dependencies.xml errors in Tool Shed testing
Hi again, I've realised that my current Blast2GO install script would be a perfect example of where this tweak to fabric_util.py would help - when I wrote the tool_dependencies.xml I didn't appreciate that the download_by_url action was only allowed as the first action - currently it is ignored if listed later in the script (just as any unknown actions are currently ignored). http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go/6e7694a0ae00 (I'm about to try and fix this tool_dependencies.xml file) Peter On Mon, May 13, 2013 at 10:34 AM, Peter Cock p.j.a.c...@googlemail.com wrote: Could I suggest an enhancement to abort on undefined action types, rough patch below (untested)? This will help give a clear error if a new command is used but the Galaxy host is too old to implement it (which is exactly the situation we'd see right now on the main Tool Shed if the new download_file action is used). Regards, Peter $ hg diff diff -r 65a81aead95e lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py --- a/lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py Sun May 12 11:52:55 2013 -0400 +++ b/lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py Mon May 13 10:29:17 2013 +0100 @@ -152,6 +152,12 @@ url = action_dict[ 'url' ] filename = url.split( '/' )[ -1 ] common_util.url_download( current_dir, filename, url ) +else: +# This will happen if the tool_dependencies.xml is using a very new action: +tool_dependency.status = app.model.ToolDependency.installation_status.ERROR +tool_dependency.error_message = Undefined action type %r % action_type +return + def log_results( command, fabric_AttributeString, file_path ): ___ 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] Test Tool Shed uploads broken
Hi Greg Dave, I just tried to upload an update to my Blast2GO wrapper on the Test Tool Shed, http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go This gave the following error, also note typo sucessfully [sic] - successfully. Internal Server Error Galaxy was unable to sucessfully complete your request URL: http://testtoolshed.g2.bx.psu.edu/upload/upload?repository_id=e4de88c47079d971 Module galaxy.web.framework.middleware.error:149 in __call__ app_iter = self.application(environ, sr_checker) Module paste.debug.prints:106 in __call__ environ, self.app) Module paste.wsgilib:543 in intercept_output app_iter = application(environ, replacement_start_response) Module paste.recursive:84 in __call__ return self.application(environ, start_response) Module paste.httpexceptions:633 in __call__ return self.application(environ, start_response) Module galaxy.web.framework.base:132 in __call__ return self.handle_request( environ, start_response ) Module galaxy.web.framework.base:190 in handle_request body = method( trans, **kwargs ) Module galaxy.web.framework:98 in decorator return func( self, trans, *args, **kwargs ) Module galaxy.webapps.tool_shed.controllers.upload:122 in upload self.upload_tar( trans, repository, tar, uploaded_file, upload_point, remove_repo_files_not_in_tar, commit_message, new_repo_alert ) Module galaxy.webapps.tool_shed.controllers.upload:326 in upload_tar undesirable_files_removed ) Module tool_shed.util.commit_util:116 in handle_directory_changes for undesirable_dir in undesirable_dirs: NameError: global name 'undesirable_dirs' is not defined 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] Test Tool Shed uploads broken
Hi Peter, Thanks for letting me know and sorry about the inconvenience. I've fixed this in 9763:9c06caa86e2a which is now on the test tool shed. Greg Von Kuster On May 17, 2013, at 5:08 AM, Peter Cock wrote: Hi Greg Dave, I just tried to upload an update to my Blast2GO wrapper on the Test Tool Shed, http://testtoolshed.g2.bx.psu.edu/view/peterjc/blast2go This gave the following error, also note typo sucessfully [sic] - successfully. Internal Server Error Galaxy was unable to sucessfully complete your request URL: http://testtoolshed.g2.bx.psu.edu/upload/upload?repository_id=e4de88c47079d971 Module galaxy.web.framework.middleware.error:149 in __call__ app_iter = self.application(environ, sr_checker) Module paste.debug.prints:106 in __call__ environ, self.app) Module paste.wsgilib:543 in intercept_output app_iter = application(environ, replacement_start_response) Module paste.recursive:84 in __call__ return self.application(environ, start_response) Module paste.httpexceptions:633 in __call__ return self.application(environ, start_response) Module galaxy.web.framework.base:132 in __call__ return self.handle_request( environ, start_response ) Module galaxy.web.framework.base:190 in handle_request body = method( trans, **kwargs ) Module galaxy.web.framework:98 in decorator return func( self, trans, *args, **kwargs ) Module galaxy.webapps.tool_shed.controllers.upload:122 in upload self.upload_tar( trans, repository, tar, uploaded_file, upload_point, remove_repo_files_not_in_tar, commit_message, new_repo_alert ) Module galaxy.webapps.tool_shed.controllers.upload:326 in upload_tar undesirable_files_removed ) Module tool_shed.util.commit_util:116 in handle_directory_changes for undesirable_dir in undesirable_dirs: NameError: global name 'undesirable_dirs' is not defined 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] Workflow: multiple input errors
It is most likely due to the cluster configuration, since on our non-cluster production machine doesn't have this behaviour. Cheers, J Joachim Jacob Contact details: http://www.bits.vib.be/index.php/about/80-team On 05/17/2013 10:16 AM, Joachim Jacob | VIB | wrote: Hi all, I have fired up an cloud instance of Galaxy, 2 persistent nodes, scalable up to 10. I have updated the code to the latest stable, after issues with not being able to select multiple input for workflows (more background: http://dev.list.galaxyproject.org/selecting-multiple-inputs-for-workflows-not-possible-anymore-td4659827.html) Running a workflow on multiple inputs (#=58) gives me - after a very long page loading - this error: Internal Server Error Galaxy was unable to sucessfully complete your request URL: http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910 Module galaxy.web.framework.middleware.error:*149* in |__call__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#app_iter *=* self*.*application*(*environ*,* sr_checker*)*| Module paste.recursive:*84* in |__call__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* self*.*application*(*environ*,* start_response*)*| Module paste.httpexceptions:*633* in |__call__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* self*.*application*(*environ*,* start_response*)*| Module galaxy.web.framework.base:*128* in |__call__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* self*.*handle_request*(* environ*,* start_response *)*| Module galaxy.web.framework.base:*184* in |handle_request| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#body *=* method*(* trans*,* kwargs *)*| Module galaxy.webapps.galaxy.controllers.workflow:*1443* in |run| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#job*,* out_data *=* tool*.*execute*(* trans*,* step*.*state*.*inputs*,* history*=*target_history*)*| Module galaxy.tools:*2342* in |execute| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* self*.*tool_action*.*execute*(* self*,* trans*,* incoming*=*incoming*,* set_output_hid*=*set_output_hid*,* history*=*history*,* kwargs *)*| Module galaxy.tools.actions:*397* in |execute| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#job*.*add_input_dataset*(* name*,* dataset *)*| Module galaxy.model:*247* in |add_input_dataset| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*input_datasets*.*append*(* JobToInputDatasetAssociation*(* name*,* dataset *)* *)*| Module ?:*4* in |__init__| Module sqlalchemy.orm.state:*82* in |initialize_instance| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#*return* manager*.*events*.*original_init*(mixed*[**1**:**]**,* kwargs*)*| Module galaxy.model:*450* in |__init__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*dataset *=* dataset| Module sqlalchemy.orm.attributes:*150* in |__set__| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*impl*.*set*(*instance_state*(*instance*)**,* instance_dict*(*instance*)**,* value*,* None*)*| Module sqlalchemy.orm.attributes:*590* in |set| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#value *=* self*.*fire_replace_event*(*state*,* dict_*,* value*,* old*,* initiator*)*| Module sqlalchemy.orm.attributes:*610* in |fire_replace_event| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#value *=* ext*.*set*(*state*,* value*,* previous*,* initiator *or* self*)*| Module sqlalchemy.orm.unitofwork:*69* in |set| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#sess*.*add*(*newvalue*)*| Module sqlalchemy.orm.session:*1091* in |add| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*_save_or_update_state*(*state*)*| Module sqlalchemy.orm.session:*1100* in |_save_or_update_state| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*_save_or_update_impl*(*state*)*| Module sqlalchemy.orm.session:*1267* in |_save_or_update_impl| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*_update_impl*(*state*)*| Module sqlalchemy.orm.session:*1259* in |_update_impl| | http://ec2-54-226-11-122.compute-1.amazonaws.com/workflow/run?id=e967e0737bb63910#self*.*_attach*(*state*)*| Module sqlalchemy.orm.session:*1286* in |_attach| |
[galaxy-dev] Add a download process to a job handler in history queue
Hello, I developed a script to download file to Galaxy from other platform. If the size of the file is large, the process may take several minutes and I can't to anything else in Galaxy. Is there a way to add the download process in a job handler and add it to history queue? Any help is more than welcome! Thank you in advance! ___ 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] Test Tool Shed uploads broken
On Fri, May 17, 2013 at 12:37 PM, Greg Von Kuster g...@bx.psu.edu wrote: Hi Peter, Thanks for letting me know and sorry about the inconvenience. I've fixed this in 9763:9c06caa86e2a which is now on the test tool shed. Greg Von Kuster Great - that works for me now :) 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/
[galaxy-dev] Cross Tool Shed dependencies / blast_datatypes
Hi Greg, Do you guys have a rough plan for when inter-ToolShed dependencies will be supported? I've been using the Test Tool Shed to validate tools before uploading them to the main Tool Shed - this uncovers things like omitted test files which I don't find locally since I'm testing in-situ. Right now the single biggest class of test failures amongst my tools on the Test Tool Shed is a missing dependencies on the blast_datatypes repository: http://toolshed.g2.bx.psu.edu/view/devteam/blast_datatypes As a short term measure, could the dev team upload blast_datatypes to the Test Tool Shed as well please (and give me write access)? Then thanks to the recent change in [1] I can reference the dependency without explicitly naming the Tool Shed. If you can do it in a way that preserves the same revision history can change set hashes even better - then I can replace this: repository toolshed=http://toolshed.g2.bx.psu.edu; name=blast_datatypes owner=devteam changeset_revision=f9a7783ed7b6 / with: repository name=blast_datatypes owner=devteam changeset_revision=f9a7783ed7b6 / and can use the same repository_dependencies.xml file on both Tool Sheds. If preserving the hashes isn't possible, I'll use the new [2] 'latest revision' ability instead: repository name=blast_datatypes owner=devteam / Thanks, Peter -- [1] https://bitbucket.org/galaxy/galaxy-central/commits/842a78530fcd87670198d55d96d9adbdfc53483e [2] https://bitbucket.org/galaxy/galaxy-central/commits/35de5a8a928bf63fd5de3d1ec066097602acf235 ___ 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] Galaxy group at Google+
Hi, I realized there was no Galaxy group on G+, although I find G+ is a really nice medium for some kind of posts, especially for things like showing off some work you have done, without disturbing others on the mailing lists. Feel free to chime in: http://gplus.to/galaxyportal Cheers, // Samuel -- Developer at SNIC-UPPMAX www.uppmax.uu.se Developer at Dept of Pharm Biosciences www.farmbio.uu.se ___ 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] tool_dependencies inside tool_dependencies
Hey All, There was a long conversation about this topic in IRC yesterday (among people who don't actually use the tool shed all that frequently), I have posted it to the new unofficial Galaxy Google+ group if anyone would like to read and chime in. https://plus.google.com/111860405027053012444/posts/TkCFwA2jkDN -John On Tue, May 14, 2013 at 3:59 PM, Nate Coraor n...@bx.psu.edu wrote: Greg created the following card, and I'm working on a few changes to your commit: https://trello.com/card/toolshed-consider-enhancing-tool-dependency-definition-framework-per-john-chilton-s-pull-request/506338ce32ae458f6d15e4b3/848 Thanks, --nate On May 14, 2013, at 1:45 PM, Nate Coraor wrote: On May 14, 2013, at 10:58 AM, John Chilton wrote: Hey Nate, On Tue, May 14, 2013 at 8:40 AM, Nate Coraor n...@bx.psu.edu wrote: Hi John, A few of us in the lab here at Penn State actually discussed automatic creation of virtualenvs for dependency installations a couple weeks ago. This was in the context of Bjoern's request for supporting compile-time dependencies. I think it's a great idea, but there's a limitation that we'd need to account for. If you're going to have frequently used and expensive to build libraries (e.g. numpy, R + rpy) in dependency-only repositories and then have your tool(s) depend on those repositories, the activate method won't work. virtualenvs cannot depend on other virtualenvs or be active at the same time as other virtualenvs. We could work around it by setting PYTHONPATH in the dependencies' env.sh like we do now. But then, other than making installation a bit easier (e.g. by allowing the use of pip), we have not gained much. I don't know what to make of your response. It seems like a no, but the word no doesn't appear anywhere. Sorry about being wishy-washy. Unless anyone has any objections or can foresee other problems, I would say yes to this. But I believe it should not break the concept of common-dependency-only repositories. I'm pretty sure that as long as the process of creating a venv also adds the venv's site-packages to PYTHONPATH in that dependency's env.sh, the problem should be automatically dealt with. I don't know the particulars of rpy, but numpy installs fine via this method and I see no problem with each application having its own copy of numpy. I think relying on OS managed python packages for instance is something of a bad practice, when developing and distributing software I use virtualenvs for everything. I think that stand-alone python defined packages in the tool shed are directly analogous to OS managed packages. Completely agree that we want to avoid OS-managed python packages. I had, in the past, considered that for something like numpy, we ought to make it easy for an administrator to allow their own version of numpy to be used, since numpy can be linked against a number of optimized libraries for significant performance gains, and this generally won't happen for versions installed from the toolshed unless the system already has stuff like atlas-dev installed. But I think we still allow admins that possibility with reasonable ease since dependency management in Galaxy is not a requirement. What we do want to avoid is the situation where someone clones a new copy of Galaxy, wants to install 10 different tools that all depend on numpy, and has to wait an hour while 10 versions of numpy compile. Add that in with other tools that will have a similar process (installing R + packages + rpy) plus the hope that down the line you'll be able to automatically maintain separate builds for remote resources that are not the same (i.e. multiple clusters with differing operating systems) and this hopefully highlights why I think reducing duplication where possible will be important. I also disagree we have not gained much. Setting up these repositories is a onerous, brittle process. This patch provides some high-level functionality for creating virtualenv's which negates the need for creating separate repositories per package. This is a good point. I probably also sold short the benefit of being able to install with pip, since this does indeed remove a similarly brittle and tedious step of downloading and installing modules. --nate -John --nate On May 13, 2013, at 6:49 PM, John Chilton wrote: The proliferation of individual python package install definitions has continued and it has spread to some MSI managed tools. I worry about the tedium I will have to endure in the future if that becomes an established best practice :) so I have implemented the python version of what I had described in this thread: As patch: https://github.com/jmchilton/galaxy-central/commit/161d3b288016077a99fb7196b6e08fe7d690f34b.patch Pretty version: https://github.com/jmchilton/galaxy-central/commit/161d3b288016077a99fb7196b6e08fe7d690f34b I understand that there are going
[galaxy-dev] very long load times for some shared libraries...
All of a sudden, some larger libraries are taking a very long time to open. [cid:BB83AE73-EAE2-44B9-B294-918CDE8C18F4@neb.com] This one timed out… Anybody else seen this? Could this be a database issue? Didn't see any really long queries in the postgres log (and i log anything longer than 1000ms) brad -- Brad Langhorst Applications and Product Development Scientist langho...@neb.commailto:langho...@neb.com inline: PastedGraphic-1.png___ 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/
