Local installation of the tool shed
Hi Greg, I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for. Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? Thanks, Nico --------------------------------------------------------------- Nicolas Delhomme Genome Biology Computational Support European Molecular Biology Laboratory Tel: +49 6221 387 8310 Email: nicolas.delhomme@embl.de Meyerhofstrasse 1 - Postfach 10.2209 69102 Heidelberg, Germany ---------------------------------------------------------------
Hello Nicolas, On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote:
Hi Greg,
I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for.
Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards.
This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing. You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process. If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional.
Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start.
This is a good approach.
Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough?
Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know. The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by: %sh run_community.sh Feel free to ask questions!
Thanks,
Nico
--------------------------------------------------------------- Nicolas Delhomme
Genome Biology Computational Support
European Molecular Biology Laboratory
Tel: +49 6221 387 8310 Email: nicolas.delhomme@embl.de Meyerhofstrasse 1 - Postfach 10.2209 69102 Heidelberg, Germany ---------------------------------------------------------------
___________________________________________________________ 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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Hello Greg We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser: Server Error An error occurred. See the error logs for more information. (Turn debug on to display exception reports here) In the logs, here is what we get: Error - <type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' URL: http://taiji/ File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ app_iter = self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ trans = self.transaction_factory( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in <lambda> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ self._ensure_logged_in_user( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user if self.app.config.ucsc_display_sites and self.request.path == display_as: AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites' Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error. What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: ucsc_display_sites: 'main,test,archaea,ucla' Did we miss anything? Where should we start searching for a possible error source? Thanks, L-A Le 23/11/2011 16:11, Greg Von Kuster a écrit :
Hello Nicolas,
On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote:
Hi Greg,
I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for.
Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards.
This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing.
You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process.
If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional.
Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. This is a good approach.
Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know.
The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by:
%sh run_community.sh
Feel free to ask questions!
Thanks,
Nico
--------------------------------------------------------------- Nicolas Delhomme
Genome Biology Computational Support
European Molecular Biology Laboratory
Tel: +49 6221 387 8310 Email: nicolas.delhomme@embl.de Meyerhofstrasse 1 - Postfach 10.2209 69102 Heidelberg, Germany ---------------------------------------------------------------
___________________________________________________________ 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/ Greg Von Kuster Galaxy Development Team greg@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:
Hello Louise, Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file. Thanks, Greg Von Kuster On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote:
Hello Greg
We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser:
Server Error An error occurred. See the error logs for more information. (Turn debug on to display exception reports here)
In the logs, here is what we get:
Error - <type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' URL: http://taiji/ File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ app_iter = self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ trans = self.transaction_factory( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in <lambda> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ self._ensure_logged_in_user( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user if self.app.config.ucsc_display_sites and self.request.path == display_as: AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites'
Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error.
What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: ucsc_display_sites: 'main,test,archaea,ucla'
Did we miss anything? Where should we start searching for a possible error source?
Thanks, L-A
Le 23/11/2011 16:11, Greg Von Kuster a écrit :
Hello Nicolas,
On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote:
Hi Greg,
I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for.
Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards.
This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing.
You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process.
If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional.
Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. This is a good approach.
Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know.
The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by:
%sh run_community.sh
Feel free to ask questions!
Thanks,
Nico
--------------------------------------------------------------- Nicolas Delhomme
Genome Biology Computational Support
European Molecular Biology Laboratory
Tel: +49 6221 387 8310 Email: nicolas.delhomme@embl.de Meyerhofstrasse 1 - Postfach 10.2209 69102 Heidelberg, Germany ---------------------------------------------------------------
___________________________________________________________ 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/ Greg Von Kuster Galaxy Development Team greg@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:
___________________________________________________________ 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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Hello Greg Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed. Thanks a lot, Louise-Amélie Le 25/11/2011 00:36, Greg Von Kuster a écrit :
Hello Louise,
Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file.
Thanks,
Greg Von Kuster
On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote:
Hello Greg
We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser:
Server Error An error occurred. See the error logs for more information. (Turn debug on to display exception reports here)
In the logs, here is what we get:
Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' URL: http://taiji/ File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ app_iter = self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ trans = self.transaction_factory( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ self._ensure_logged_in_user( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user if self.app.config.ucsc_display_sites and self.request.path == display_as: AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites'
Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error.
What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: ucsc_display_sites: 'main,test,archaea,ucla'
Did we miss anything? Where should we start searching for a possible error source?
Thanks, L-A
Le 23/11/2011 16:11, Greg Von Kuster a écrit :
Hello Nicolas,
On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote:
Hi Greg,
I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for.
Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing.
You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process.
If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional.
Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. This is a good approach.
Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know.
The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by:
%sh run_community.sh
Feel free to ask questions!
Thanks,
Nico
--------------------------------------------------------------- Nicolas Delhomme
Genome Biology Computational Support
European Molecular Biology Laboratory
Tel: +49 6221 387 8310 Email: nicolas.delhomme@embl.de Meyerhofstrasse 1 - Postfach 10.2209 69102 Heidelberg, Germany ---------------------------------------------------------------
___________________________________________________________ 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/ Greg Von Kuster Galaxy Development Team greg@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:
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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Hello Louise-Amelie, I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own. # -- Display sites # Galaxy can display data at various external browsers. These options specify # which browsers should be available. URLs and builds available at these # browsers are defined in the specifield files. # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt ucsc_display_sites = main,test,archaea,ucla # GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd # GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt genetrack_display_sites = main,test On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote:
Hello Greg
Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed.
Thanks a lot, Louise-Amélie
Le 25/11/2011 00:36, Greg Von Kuster a écrit :
Hello Louise,
Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file.
Thanks,
Greg Von Kuster
On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote:
Hello Greg
We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser:
Server Error An error occurred. See the error logs for more information. (Turn debug on to display exception reports here)
In the logs, here is what we get:
Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' URL: http://taiji/ File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ app_iter = self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ trans = self.transaction_factory( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ self._ensure_logged_in_user( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user if self.app.config.ucsc_display_sites and self.request.path == display_as: AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites'
Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error.
What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: ucsc_display_sites: 'main,test,archaea,ucla'
Did we miss anything? Where should we start searching for a possible error source?
Thanks, L-A
Le 23/11/2011 16:11, Greg Von Kuster a écrit :
Hello Nicolas,
On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote:
Hi Greg,
I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for.
Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing.
You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process.
If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional.
Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. This is a good approach.
Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know.
The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by:
%sh run_community.sh
Feel free to ask questions!
Thanks,
Nico
--------------------------------------------------------------- Nicolas Delhomme
Genome Biology Computational Support
European Molecular Biology Laboratory
Tel: +49 6221 387 8310 Email: nicolas.delhomme@embl.de Meyerhofstrasse 1 - Postfach 10.2209 69102 Heidelberg, Germany ---------------------------------------------------------------
___________________________________________________________ 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/ Greg Von Kuster Galaxy Development Team greg@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:
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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
<community_wsgi.ini><run_community.sh>___________________________________________________________ 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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Hello Greg, This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then. Do you have any other idea that we could explore? Do you need other files? Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates Thanks, L-A Le 25/11/2011 14:07, Greg Von Kuster a écrit :
Hello Louise-Amelie,
I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own.
# -- Display sites
# Galaxy can display data at various external browsers. These options specify # which browsers should be available. URLs and builds available at these # browsers are defined in the specifield files.
# UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt ucsc_display_sites = main,test,archaea,ucla
# GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd
# GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt genetrack_display_sites = main,test
On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote:
Hello Greg
Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed.
Thanks a lot, Louise-Amélie
Le 25/11/2011 00:36, Greg Von Kuster a écrit :
Hello Louise,
Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file.
Thanks,
Greg Von Kuster
On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote:
Hello Greg
We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser:
Server Error An error occurred. See the error logs for more information. (Turn debug on to display exception reports here)
In the logs, here is what we get:
Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' URL: http://taiji/ File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ app_iter = self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ trans = self.transaction_factory( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ self._ensure_logged_in_user( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user if self.app.config.ucsc_display_sites and self.request.path == display_as: AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites'
Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error.
What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: ucsc_display_sites: 'main,test,archaea,ucla'
Did we miss anything? Where should we start searching for a possible error source?
Thanks, L-A
Le 23/11/2011 16:11, Greg Von Kuster a écrit :
Hello Nicolas,
On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote:
Hi Greg,
I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for.
Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing.
You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process.
If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional.
Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. This is a good approach.
Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know.
The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by:
%sh run_community.sh
Feel free to ask questions!
Thanks,
Nico
--------------------------------------------------------------- Nicolas Delhomme
Genome Biology Computational Support
European Molecular Biology Laboratory
Tel: +49 6221 387 8310 Email: nicolas.delhomme@embl.de <mailto:nicolas.delhomme@embl.de> Meyerhofstrasse 1 - Postfach 10.2209 69102 Heidelberg, Germany ---------------------------------------------------------------
___________________________________________________________ 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/ Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@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:
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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
<community_wsgi.ini><run_community.sh>___________________________________________________________ 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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server? On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
Hello Greg,
This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then.
Do you have any other idea that we could explore? Do you need other files?
Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates
Thanks, L-A
Le 25/11/2011 14:07, Greg Von Kuster a écrit :
Hello Louise-Amelie,
I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own.
# -- Display sites
# Galaxy can display data at various external browsers. These options specify # which browsers should be available. URLs and builds available at these # browsers are defined in the specifield files.
# UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt ucsc_display_sites = main,test,archaea,ucla
# GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd
# GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt genetrack_display_sites = main,test
On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote:
Hello Greg
Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed.
Thanks a lot, Louise-Amélie
Le 25/11/2011 00:36, Greg Von Kuster a écrit :
Hello Louise,
Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file.
Thanks,
Greg Von Kuster
On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote:
Hello Greg
We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser:
Server Error An error occurred. See the error logs for more information. (Turn debug on to display exception reports here)
In the logs, here is what we get:
Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' URL: http://taiji/ File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ app_iter = self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ trans = self.transaction_factory( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ self._ensure_logged_in_user( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user if self.app.config.ucsc_display_sites and self.request.path == display_as: AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites'
Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error.
What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: ucsc_display_sites: 'main,test,archaea,ucla'
Did we miss anything? Where should we start searching for a possible error source?
Thanks, L-A
Le 23/11/2011 16:11, Greg Von Kuster a écrit :
Hello Nicolas,
On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote:
> Hi Greg, > > I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for. > > Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing.
You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process.
If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional.
> Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. This is a good approach.
> Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know.
The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by:
%sh run_community.sh
Feel free to ask questions!
> Thanks, > > Nico > > > --------------------------------------------------------------- > Nicolas Delhomme > > Genome Biology Computational Support > > European Molecular Biology Laboratory > > Tel: +49 6221 387 8310 > Email: nicolas.delhomme@embl.de > Meyerhofstrasse 1 - Postfach 10.2209 > 69102 Heidelberg, Germany > --------------------------------------------------------------- > > > > > > > ___________________________________________________________ > 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/ Greg Von Kuster Galaxy Development Team greg@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:
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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
<community_wsgi.ini><run_community.sh>___________________________________________________________ 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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Here is the full log: http://pastebin.com/qvB6UqxF Le 25/11/2011 14:33, Greg Von Kuster a écrit :
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server?
On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
Hello Greg,
This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then.
Do you have any other idea that we could explore? Do you need other files?
Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates
Thanks, L-A
Le 25/11/2011 14:07, Greg Von Kuster a écrit :
Hello Louise-Amelie,
I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own.
# -- Display sites
# Galaxy can display data at various external browsers. These options specify # which browsers should be available. URLs and builds available at these # browsers are defined in the specifield files.
# UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt ucsc_display_sites = main,test,archaea,ucla
# GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd
# GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt genetrack_display_sites = main,test
On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote:
Hello Greg
Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed.
Thanks a lot, Louise-Amélie
Le 25/11/2011 00:36, Greg Von Kuster a écrit :
Hello Louise,
Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file.
Thanks,
Greg Von Kuster
On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote:
Hello Greg
We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser:
Server Error An error occurred. See the error logs for more information. (Turn debug on to display exception reports here)
In the logs, here is what we get:
Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' URL: http://taiji/ File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ app_iter = self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ return self.application(environ, start_response) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ trans = self.transaction_factory( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ self._ensure_logged_in_user( environ ) File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user if self.app.config.ucsc_display_sites and self.request.path == display_as: AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites'
Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error.
What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: ucsc_display_sites: 'main,test,archaea,ucla'
Did we miss anything? Where should we start searching for a possible error source?
Thanks, L-A
Le 23/11/2011 16:11, Greg Von Kuster a écrit : > Hello Nicolas, > > On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: > >> Hi Greg, >> >> I've been scanning the mailing list, but wasn't lucky enough to >> find the answer I was looking for. >> >> Basically, we would be interested to have our own Galaxy Tool >> Shed in-house, to develop and test tools within our local >> Galaxy instance. What I'm thinking of, is to use the power of >> the tool shed to develop new algorithm, new tools, etc. that >> could be published afterwards. > This is great, but keep in mind that the intent of the tool shed > (whether it is a local, proprietary tool shed or the public > Galaxy tool shed) is to provide a vehicle for sharing tools (and > tool-related objects like workflows, data types, etc) that are > determined to be functional within a Galaxy instance. So the > primary use of a tool shed should be to enable sharing. The > tools themselves should be implemented within a development > environment that includes a Galaxy instance, and when a tool is > deemed functional, it can then be uploaded to the tool shed for > sharing. > > You can, however, tweak the primary intent of a tool shed to > meet your needs. In your case, it seems that you may be > interested in using a local tool shed instance to share tools > between developers during the development process. If this is > the case, then your approach can be one where a developer > creates a repository on the local tool shed multiple developers > can clone it. The mercurial command line process for > committing, pushing, pulling and updating can be used to share > updates to the tool code by multiple developers throughout the > process. > > If a single developer is implementing the tool however, it may > make more sense to not use the tool shed as part of the > development process - just upload the tool when it is functional. > > >> Because these would be sensitive material, we would not want to >> put them right away on the public test Tool Shed. Having a >> local Tool Shed instance would still be very helpful in >> releasing these tools to the community afterwards, as they >> would have been integrated and developed within that framework >> from the start. > This is a good approach. > >> Any pointers on how to achieve this are welcome as I'm not so >> familiar with the Tool Shed yet, e.g. would making a local >> clone of the tool shed repository be enough? > Make sure to read the tool shed wiki at > http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this > up-to-date with the latest features of the tool shed. You'll > ffind, however, that there are some tool shed admin user > features that have not yet been documented. If you have any > question, let me know. > > The tool shed is included in the Galaxy distribution, so no > additional cloning is necessary - it is just a different webpp > from Galaxy itself. It uses a different database from Galaxy, > which you configure in the file community_wsgi.ini (the > equivalent of universe_wsgi.ini for Galxy). After you have the > configuration settings as you want them, start up your local > tool shed by: > > %sh run_community.sh > > Feel free to ask questions! > > >> Thanks, >> >> Nico >> >> >> --------------------------------------------------------------- >> Nicolas Delhomme >> >> Genome Biology Computational Support >> >> European Molecular Biology Laboratory >> >> Tel: +49 6221 387 8310 >> Email: nicolas.delhomme@embl.de <mailto:nicolas.delhomme@embl.de> >> Meyerhofstrasse 1 - Postfach 10.2209 >> 69102 Heidelberg, Germany >> --------------------------------------------------------------- >> >> >> >> >> >> >> ___________________________________________________________ >> 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/ > Greg Von Kuster > Galaxy Development Team > greg@bx.psu.edu <mailto:greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
<community_wsgi.ini><run_community.sh>___________________________________________________________ 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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Louise-Amelie, The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience. # Where templates are stored template_path = lib/galaxy/webapps/community/templates On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit :
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server?
On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
Hello Greg,
This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then.
Do you have any other idea that we could explore? Do you need other files?
Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates
Thanks, L-A
Le 25/11/2011 14:07, Greg Von Kuster a écrit :
Hello Louise-Amelie,
I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own.
# -- Display sites
# Galaxy can display data at various external browsers. These options specify # which browsers should be available. URLs and builds available at these # browsers are defined in the specifield files.
# UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt ucsc_display_sites = main,test,archaea,ucla
# GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd
# GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt genetrack_display_sites = main,test
On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote:
Hello Greg
Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed.
Thanks a lot, Louise-Amélie
Le 25/11/2011 00:36, Greg Von Kuster a écrit :
Hello Louise,
Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file.
Thanks,
Greg Von Kuster
On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote:
> Hello Greg > > We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser: > > Server Error > An error occurred. See the error logs for more information. (Turn debug on to display exception reports here) > > In the logs, here is what we get: > > Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' > URL: http://taiji/ > File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ > app_iter = self.application(environ, start_response) > File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ > return self.application(environ, start_response) > File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ > return self.application(environ, start_response) > File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ > trans = self.transaction_factory( environ ) > File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> > self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) > File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser > return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) > File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ > self._ensure_logged_in_user( environ ) > File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user > if self.app.config.ucsc_display_sites and self.request.path == display_as: > AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites' > > Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error. > > What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: > ucsc_display_sites: 'main,test,archaea,ucla' > > Did we miss anything? Where should we start searching for a possible error source? > > Thanks, > L-A > > > > Le 23/11/2011 16:11, Greg Von Kuster a écrit : >> Hello Nicolas, >> >> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >> >>> Hi Greg, >>> >>> I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for. >>> >>> Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. >> This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing. >> >> You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process. >> >> If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional. >> >> >>> Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. >> This is a good approach. >> >>> Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? >> Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know. >> >> The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by: >> >> %sh run_community.sh >> >> Feel free to ask questions! >> >> >>> Thanks, >>> >>> Nico >>> >>> >>> --------------------------------------------------------------- >>> Nicolas Delhomme >>> >>> Genome Biology Computational Support >>> >>> European Molecular Biology Laboratory >>> >>> Tel: +49 6221 387 8310 >>> Email: nicolas.delhomme@embl.de >>> Meyerhofstrasse 1 - Postfach 10.2209 >>> 69102 Heidelberg, Germany >>> --------------------------------------------------------------- >>> >>> >>> >>> >>> >>> >>> ___________________________________________________________ >>> 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/ >> Greg Von Kuster >> Galaxy Development Team >> greg@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/ > Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
<community_wsgi.ini><run_community.sh>___________________________________________________________ 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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Well, the symlink is indeed not needed anymore, thanks for the fix. However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A Hope that helps L-A Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit :
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server?
On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
Hello Greg,
This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then.
Do you have any other idea that we could explore? Do you need other files?
Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates
Thanks, L-A
Le 25/11/2011 14:07, Greg Von Kuster a écrit :
Hello Louise-Amelie,
I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own.
# -- Display sites
# Galaxy can display data at various external browsers. These options specify # which browsers should be available. URLs and builds available at these # browsers are defined in the specifield files.
# UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt ucsc_display_sites = main,test,archaea,ucla
# GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd
# GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt genetrack_display_sites = main,test
On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote:
Hello Greg
Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed.
Thanks a lot, Louise-Amélie
Le 25/11/2011 00:36, Greg Von Kuster a écrit : > Hello Louise, > > Can you send me your community_wsgi.ini file? I assume your > copied it from community_wsgi.ini.sample, but somehow it looks > like your configuration settings are attempting to start the > Galaxy server instead of the tool shed server. I should be able > to sort it out for you by looking at your configuration file. > > Thanks, > > Greg Von Kuster > > On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: > >> Hello Greg >> >> We tried to run the toolshed like you explained (thanks a lot >> for the quick answer btw), it starts fine, but when we try to >> access it on the web, we get this error in the browser: >> >> Server Error >> An error occurred. See the error logs for more information. >> (Turn debug on to display exception reports here) >> >> In the logs, here is what we get: >> >> Error -<type 'exceptions.AttributeError'>: 'Configuration' >> object has no attribute 'ucsc_display_sites' >> URL: http://taiji/ >> File >> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', >> line 143 in __call__ >> app_iter = self.application(environ, start_response) >> File >> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', >> line 80 in __call__ >> return self.application(environ, start_response) >> File >> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', >> line 632 in __call__ >> return self.application(environ, start_response) >> File >> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', >> line 134 in __call__ >> trans = self.transaction_factory( environ ) >> File >> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >> line 187 in<lambda> >> self.set_transaction_factory( lambda e: >> self.transaction_chooser( e, galaxy_app, session_cookie ) ) >> File >> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >> line 207 in transaction_chooser >> return GalaxyWebUITransaction( environ, galaxy_app, self, >> session_cookie ) >> File >> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >> line 860 in __init__ >> self._ensure_logged_in_user( environ ) >> File >> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >> line 420 in _ensure_logged_in_user >> if self.app.config.ucsc_display_sites and self.request.path == >> display_as: >> AttributeError: 'Configuration' object has no attribute >> 'ucsc_display_sites' >> >> Since this name ringed a bell, I checked the universe_wsgi.ini >> and found this "Display sites" section. I therefore copied it >> and pasted it in the community.wsgi.ini file and uncommented >> the variables in this section. But when we tried again, we >> still get the same error. >> >> What is confusing, is that after the error message, all the >> CGI, congifuration and WSGI variables are displayed, and in the >> configuration section we have this line: >> ucsc_display_sites: 'main,test,archaea,ucla' >> >> Did we miss anything? Where should we start searching for a >> possible error source? >> >> Thanks, >> L-A >> >> >> >> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>> Hello Nicolas, >>> >>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>> >>>> Hi Greg, >>>> >>>> I've been scanning the mailing list, but wasn't lucky enough >>>> to find the answer I was looking for. >>>> >>>> Basically, we would be interested to have our own Galaxy Tool >>>> Shed in-house, to develop and test tools within our local >>>> Galaxy instance. What I'm thinking of, is to use the power of >>>> the tool shed to develop new algorithm, new tools, etc. that >>>> could be published afterwards. >>> This is great, but keep in mind that the intent of the tool >>> shed (whether it is a local, proprietary tool shed or the >>> public Galaxy tool shed) is to provide a vehicle for sharing >>> tools (and tool-related objects like workflows, data types, >>> etc) that are determined to be functional within a Galaxy >>> instance. So the primary use of a tool shed should be to >>> enable sharing. The tools themselves should be implemented >>> within a development environment that includes a Galaxy >>> instance, and when a tool is deemed functional, it can then be >>> uploaded to the tool shed for sharing. >>> >>> You can, however, tweak the primary intent of a tool shed to >>> meet your needs. In your case, it seems that you may be >>> interested in using a local tool shed instance to share tools >>> between developers during the development process. If this is >>> the case, then your approach can be one where a developer >>> creates a repository on the local tool shed multiple >>> developers can clone it. The mercurial command line process >>> for committing, pushing, pulling and updating can be used to >>> share updates to the tool code by multiple developers >>> throughout the process. >>> >>> If a single developer is implementing the tool however, it may >>> make more sense to not use the tool shed as part of the >>> development process - just upload the tool when it is functional. >>> >>> >>>> Because these would be sensitive material, we would not want >>>> to put them right away on the public test Tool Shed. Having a >>>> local Tool Shed instance would still be very helpful in >>>> releasing these tools to the community afterwards, as they >>>> would have been integrated and developed within that >>>> framework from the start. >>> This is a good approach. >>> >>>> Any pointers on how to achieve this are welcome as I'm not so >>>> familiar with the Tool Shed yet, e.g. would making a local >>>> clone of the tool shed repository be enough? >>> Make sure to read the tool shed wiki at >>> http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep >>> this up-to-date with the latest features of the tool shed. >>> You'll ffind, however, that there are some tool shed admin >>> user features that have not yet been documented. If you have >>> any question, let me know. >>> >>> The tool shed is included in the Galaxy distribution, so no >>> additional cloning is necessary - it is just a different webpp >>> from Galaxy itself. It uses a different database from Galaxy, >>> which you configure in the file community_wsgi.ini (the >>> equivalent of universe_wsgi.ini for Galxy). After you have >>> the configuration settings as you want them, start up your >>> local tool shed by: >>> >>> %sh run_community.sh >>> >>> Feel free to ask questions! >>> >>> >>>> Thanks, >>>> >>>> Nico >>>> >>>> >>>> --------------------------------------------------------------- >>>> Nicolas Delhomme >>>> >>>> Genome Biology Computational Support >>>> >>>> European Molecular Biology Laboratory >>>> >>>> Tel: +49 6221 387 8310 >>>> Email: nicolas.delhomme@embl.de <mailto:nicolas.delhomme@embl.de> >>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>> 69102 Heidelberg, Germany >>>> --------------------------------------------------------------- >>>> >>>> >>>> >>>> >>>> >>>> >>>> ___________________________________________________________ >>>> 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/ >>> Greg Von Kuster >>> Galaxy Development Team >>> greg@bx.psu.edu <mailto:greg@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/ >> > Greg Von Kuster > Galaxy Development Team > greg@bx.psu.edu <mailto:greg@bx.psu.edu> > > >
<community_wsgi.ini><run_community.sh>___________________________________________________________ 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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help! # Force everyone to log in (disable anonymous access) require_login = True On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit :
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server?
On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
Hello Greg,
This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then.
Do you have any other idea that we could explore? Do you need other files?
Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates
Thanks, L-A
Le 25/11/2011 14:07, Greg Von Kuster a écrit :
Hello Louise-Amelie,
I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own.
# -- Display sites
# Galaxy can display data at various external browsers. These options specify # which browsers should be available. URLs and builds available at these # browsers are defined in the specifield files.
# UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt ucsc_display_sites = main,test,archaea,ucla
# GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd
# GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt genetrack_display_sites = main,test
On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote:
> Hello Greg > > Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed. > > Thanks a lot, > Louise-Amélie > > > Le 25/11/2011 00:36, Greg Von Kuster a écrit : >> Hello Louise, >> >> Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file. >> >> Thanks, >> >> Greg Von Kuster >> >> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >> >>> Hello Greg >>> >>> We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser: >>> >>> Server Error >>> An error occurred. See the error logs for more information. (Turn debug on to display exception reports here) >>> >>> In the logs, here is what we get: >>> >>> Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' >>> URL: http://taiji/ >>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ >>> app_iter = self.application(environ, start_response) >>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ >>> return self.application(environ, start_response) >>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ >>> return self.application(environ, start_response) >>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ >>> trans = self.transaction_factory( environ ) >>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> >>> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser >>> return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) >>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ >>> self._ensure_logged_in_user( environ ) >>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user >>> if self.app.config.ucsc_display_sites and self.request.path == display_as: >>> AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites' >>> >>> Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error. >>> >>> What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: >>> ucsc_display_sites: 'main,test,archaea,ucla' >>> >>> Did we miss anything? Where should we start searching for a possible error source? >>> >>> Thanks, >>> L-A >>> >>> >>> >>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>> Hello Nicolas, >>>> >>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>> >>>>> Hi Greg, >>>>> >>>>> I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for. >>>>> >>>>> Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. >>>> This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing. >>>> >>>> You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process. >>>> >>>> If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional. >>>> >>>> >>>>> Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. >>>> This is a good approach. >>>> >>>>> Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? >>>> Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know. >>>> >>>> The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by: >>>> >>>> %sh run_community.sh >>>> >>>> Feel free to ask questions! >>>> >>>> >>>>> Thanks, >>>>> >>>>> Nico >>>>> >>>>> >>>>> --------------------------------------------------------------- >>>>> Nicolas Delhomme >>>>> >>>>> Genome Biology Computational Support >>>>> >>>>> European Molecular Biology Laboratory >>>>> >>>>> Tel: +49 6221 387 8310 >>>>> Email: nicolas.delhomme@embl.de >>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>> 69102 Heidelberg, Germany >>>>> --------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ___________________________________________________________ >>>>> 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/ >>>> Greg Von Kuster >>>> Galaxy Development Team >>>> greg@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/ >>> >> Greg Von Kuster >> Galaxy Development Team >> greg@bx.psu.edu >> >> >> > > <community_wsgi.ini><run_community.sh>___________________________________________________________ > 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/
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Woohoo thanks a lot, it works! :) Well almost, but at least we have something displayed. I guess there are some rewriterules missing (or just plain wrong) in our apache config file: No css or image are used and we get this error: Not Found The requested URL /repository/browse_categories was not found on this server. Here are the rules: RewriteEngine on RewriteRule ^/toolshed$ /toolshed/ [R] RewriteRule ^/toolshed/static/style/(.*) /home/galaxy/galaxy-dev/static/june_2007_style/blue/$1 [L] RewriteRule ^/toolshed/static/(.*) /home/galaxy/galaxy-dev/static/$1 [L] RewriteRule ^/toolshed/images/(.*) /home/galaxy/galaxy-dev/static/images/$1 [L] RewriteRule ^/toolshed/upload/(.*) /home/galaxy/galaxy-dev/static/automated_upload/$1 [L] RewriteRule ^/toolshed/favicon.ico /home/galaxy/galaxy-dev/static/favicon.ico [L] RewriteRule ^/toolshed/robots.txt /home/galaxy/galaxy-dev/static/robots.txt [L] RewriteRule ^/toolshed(.*) http://localhost:9009$1 [P] I kinda guessed them from what we had for galaxy, but most likely completely failed at it... Maybe you could give us some guidelines for the toolshed apache config file, like there is for galaxy in the wiki? Thanks, L-A Le 25/11/2011 16:44, Greg Von Kuster a écrit :
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help!
# Force everyone to log in (disable anonymous access) require_login = True
On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit :
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server?
On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
Hello Greg,
This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then.
Do you have any other idea that we could explore? Do you need other files?
Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates
Thanks, L-A
Le 25/11/2011 14:07, Greg Von Kuster a écrit : > Hello Louise-Amelie, > > I believe the problem is caused by the inclusion of the > following settings in your community_webapp.ini file. This > sections should not be included in the tool shed config, so if > you remove it things should work. Let me know if you bump into > other issues. I apologize for the difficulty you've had in > getting your own local tool shed up and running. The tool shed > wiki currently focuses on using the Galaxy public tool sheds, so > I'll next add a section providing details for setting up your own. > > # -- Display sites > > # Galaxy can display data at various external browsers. These > options specify > # which browsers should be available. URLs and builds available > at these > # browsers are defined in the specifield files. > > # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt > ucsc_display_sites = main,test,archaea,ucla > > # GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt > gbrowse_display_sites = > wormbase,tair,modencode_worm,modencode_fly,yeast_sgd > > # GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt > genetrack_display_sites = main,test > > > On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote: > >> Hello Greg >> >> Please find attached the file you asked for. Just in case, I >> also sent you the run_community.sh script we use to start the >> toolshed. >> >> Thanks a lot, >> Louise-Amélie >> >> >> Le 25/11/2011 00:36, Greg Von Kuster a écrit : >>> Hello Louise, >>> >>> Can you send me your community_wsgi.ini file? I assume your >>> copied it from community_wsgi.ini.sample, but somehow it looks >>> like your configuration settings are attempting to start the >>> Galaxy server instead of the tool shed server. I should be >>> able to sort it out for you by looking at your configuration file. >>> >>> Thanks, >>> >>> Greg Von Kuster >>> >>> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >>> >>>> Hello Greg >>>> >>>> We tried to run the toolshed like you explained (thanks a lot >>>> for the quick answer btw), it starts fine, but when we try to >>>> access it on the web, we get this error in the browser: >>>> >>>> Server Error >>>> An error occurred. See the error logs for more information. >>>> (Turn debug on to display exception reports here) >>>> >>>> In the logs, here is what we get: >>>> >>>> Error -<type 'exceptions.AttributeError'>: 'Configuration' >>>> object has no attribute 'ucsc_display_sites' >>>> URL: http://taiji/ >>>> File >>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', >>>> line 143 in __call__ >>>> app_iter = self.application(environ, start_response) >>>> File >>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', >>>> line 80 in __call__ >>>> return self.application(environ, start_response) >>>> File >>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', >>>> line 632 in __call__ >>>> return self.application(environ, start_response) >>>> File >>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', >>>> line 134 in __call__ >>>> trans = self.transaction_factory( environ ) >>>> File >>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>> line 187 in<lambda> >>>> self.set_transaction_factory( lambda e: >>>> self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>>> File >>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>> line 207 in transaction_chooser >>>> return GalaxyWebUITransaction( environ, galaxy_app, self, >>>> session_cookie ) >>>> File >>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>> line 860 in __init__ >>>> self._ensure_logged_in_user( environ ) >>>> File >>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>> line 420 in _ensure_logged_in_user >>>> if self.app.config.ucsc_display_sites and self.request.path >>>> == display_as: >>>> AttributeError: 'Configuration' object has no attribute >>>> 'ucsc_display_sites' >>>> >>>> Since this name ringed a bell, I checked the >>>> universe_wsgi.ini and found this "Display sites" section. I >>>> therefore copied it and pasted it in the community.wsgi.ini >>>> file and uncommented the variables in this section. But when >>>> we tried again, we still get the same error. >>>> >>>> What is confusing, is that after the error message, all the >>>> CGI, congifuration and WSGI variables are displayed, and in >>>> the configuration section we have this line: >>>> ucsc_display_sites: 'main,test,archaea,ucla' >>>> >>>> Did we miss anything? Where should we start searching for a >>>> possible error source? >>>> >>>> Thanks, >>>> L-A >>>> >>>> >>>> >>>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>>> Hello Nicolas, >>>>> >>>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>>> >>>>>> Hi Greg, >>>>>> >>>>>> I've been scanning the mailing list, but wasn't lucky >>>>>> enough to find the answer I was looking for. >>>>>> >>>>>> Basically, we would be interested to have our own Galaxy >>>>>> Tool Shed in-house, to develop and test tools within our >>>>>> local Galaxy instance. What I'm thinking of, is to use the >>>>>> power of the tool shed to develop new algorithm, new tools, >>>>>> etc. that could be published afterwards. >>>>> This is great, but keep in mind that the intent of the tool >>>>> shed (whether it is a local, proprietary tool shed or the >>>>> public Galaxy tool shed) is to provide a vehicle for sharing >>>>> tools (and tool-related objects like workflows, data types, >>>>> etc) that are determined to be functional within a Galaxy >>>>> instance. So the primary use of a tool shed should be to >>>>> enable sharing. The tools themselves should be implemented >>>>> within a development environment that includes a Galaxy >>>>> instance, and when a tool is deemed functional, it can then >>>>> be uploaded to the tool shed for sharing. >>>>> >>>>> You can, however, tweak the primary intent of a tool shed to >>>>> meet your needs. In your case, it seems that you may be >>>>> interested in using a local tool shed instance to share >>>>> tools between developers during the development process. If >>>>> this is the case, then your approach can be one where a >>>>> developer creates a repository on the local tool shed >>>>> multiple developers can clone it. The mercurial command >>>>> line process for committing, pushing, pulling and updating >>>>> can be used to share updates to the tool code by multiple >>>>> developers throughout the process. >>>>> >>>>> If a single developer is implementing the tool however, it >>>>> may make more sense to not use the tool shed as part of the >>>>> development process - just upload the tool when it is >>>>> functional. >>>>> >>>>> >>>>>> Because these would be sensitive material, we would not >>>>>> want to put them right away on the public test Tool Shed. >>>>>> Having a local Tool Shed instance would still be very >>>>>> helpful in releasing these tools to the community >>>>>> afterwards, as they would have been integrated and >>>>>> developed within that framework from the start. >>>>> This is a good approach. >>>>> >>>>>> Any pointers on how to achieve this are welcome as I'm not >>>>>> so familiar with the Tool Shed yet, e.g. would making a >>>>>> local clone of the tool shed repository be enough? >>>>> Make sure to read the tool shed wiki at >>>>> http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep >>>>> this up-to-date with the latest features of the tool shed. >>>>> You'll ffind, however, that there are some tool shed admin >>>>> user features that have not yet been documented. If you >>>>> have any question, let me know. >>>>> >>>>> The tool shed is included in the Galaxy distribution, so no >>>>> additional cloning is necessary - it is just a different >>>>> webpp from Galaxy itself. It uses a different database from >>>>> Galaxy, which you configure in the file community_wsgi.ini >>>>> (the equivalent of universe_wsgi.ini for Galxy). After you >>>>> have the configuration settings as you want them, start up >>>>> your local tool shed by: >>>>> >>>>> %sh run_community.sh >>>>> >>>>> Feel free to ask questions! >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Nico >>>>>> >>>>>> >>>>>> --------------------------------------------------------------- >>>>>> Nicolas Delhomme >>>>>> >>>>>> Genome Biology Computational Support >>>>>> >>>>>> European Molecular Biology Laboratory >>>>>> >>>>>> Tel: +49 6221 387 8310 >>>>>> Email: nicolas.delhomme@embl.de >>>>>> <mailto:nicolas.delhomme@embl.de> >>>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>>> 69102 Heidelberg, Germany >>>>>> --------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ___________________________________________________________ >>>>>> 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/ >>>>> Greg Von Kuster >>>>> Galaxy Development Team >>>>> greg@bx.psu.edu <mailto:greg@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/ >>>> >>> Greg Von Kuster >>> Galaxy Development Team >>> greg@bx.psu.edu <mailto:greg@bx.psu.edu> >>> >>> >>> >> >> <community_wsgi.ini><run_community.sh>___________________________________________________________ >> 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/ > > Greg Von Kuster > Galaxy Development Team > greg@bx.psu.edu <mailto:greg@bx.psu.edu> > > >
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Apache front-ends are not my area of expertise ( Nate may be needed for this ), but if you send me your apache settings that your use for Galaxy, I may be able to help. The tool shed uses the same static files as Galaxy, so they should be fine. Possibly the only issue is rewrites for new paths (although again, I'm not very knowledgable on apache with regard to rewrites). Here are the routes used in the tool shed if this helps. webapp.add_route( '/:controller/:action', action='index' ) webapp.add_route( '/:action', controller='repository', action='index' ) webapp.add_route( '/repos/*path_info', controller='hg', action='handle_request', path_info='/' ) On Nov 25, 2011, at 11:00 AM, Louise-Amélie Schmitt wrote:
Woohoo thanks a lot, it works! :)
Well almost, but at least we have something displayed. I guess there are some rewriterules missing (or just plain wrong) in our apache config file: No css or image are used and we get this error: Not Found
The requested URL /repository/browse_categories was not found on this server. Here are the rules:
RewriteEngine on RewriteRule ^/toolshed$ /toolshed/ [R] RewriteRule ^/toolshed/static/style/(.*) /home/galaxy/galaxy-dev/static/june_2007_style/blue/$1 [L] RewriteRule ^/toolshed/static/(.*) /home/galaxy/galaxy-dev/static/$1 [L] RewriteRule ^/toolshed/images/(.*) /home/galaxy/galaxy-dev/static/images/$1 [L] RewriteRule ^/toolshed/upload/(.*) /home/galaxy/galaxy-dev/static/automated_upload/$1 [L] RewriteRule ^/toolshed/favicon.ico /home/galaxy/galaxy-dev/static/favicon.ico [L] RewriteRule ^/toolshed/robots.txt /home/galaxy/galaxy-dev/static/robots.txt [L] RewriteRule ^/toolshed(.*) http://localhost:9009$1 [P]
I kinda guessed them from what we had for galaxy, but most likely completely failed at it... Maybe you could give us some guidelines for the toolshed apache config file, like there is for galaxy in the wiki?
Thanks, L-A
Le 25/11/2011 16:44, Greg Von Kuster a écrit :
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help!
# Force everyone to log in (disable anonymous access) require_login = True
On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit :
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server?
On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
> Hello Greg, > > This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then. > > Do you have any other idea that we could explore? Do you need other files? > > Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: > ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates > > Thanks, > L-A > > > > Le 25/11/2011 14:07, Greg Von Kuster a écrit : >> >> Hello Louise-Amelie, >> >> I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own. >> >> # -- Display sites >> >> # Galaxy can display data at various external browsers. These options specify >> # which browsers should be available. URLs and builds available at these >> # browsers are defined in the specifield files. >> >> # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt >> ucsc_display_sites = main,test,archaea,ucla >> >> # GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt >> gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd >> >> # GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt >> genetrack_display_sites = main,test >> >> >> On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote: >> >>> Hello Greg >>> >>> Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed. >>> >>> Thanks a lot, >>> Louise-Amélie >>> >>> >>> Le 25/11/2011 00:36, Greg Von Kuster a écrit : >>>> Hello Louise, >>>> >>>> Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file. >>>> >>>> Thanks, >>>> >>>> Greg Von Kuster >>>> >>>> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >>>> >>>>> Hello Greg >>>>> >>>>> We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser: >>>>> >>>>> Server Error >>>>> An error occurred. See the error logs for more information. (Turn debug on to display exception reports here) >>>>> >>>>> In the logs, here is what we get: >>>>> >>>>> Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' >>>>> URL: http://taiji/ >>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ >>>>> app_iter = self.application(environ, start_response) >>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ >>>>> return self.application(environ, start_response) >>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ >>>>> return self.application(environ, start_response) >>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ >>>>> trans = self.transaction_factory( environ ) >>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> >>>>> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser >>>>> return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) >>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ >>>>> self._ensure_logged_in_user( environ ) >>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user >>>>> if self.app.config.ucsc_display_sites and self.request.path == display_as: >>>>> AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites' >>>>> >>>>> Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error. >>>>> >>>>> What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: >>>>> ucsc_display_sites: 'main,test,archaea,ucla' >>>>> >>>>> Did we miss anything? Where should we start searching for a possible error source? >>>>> >>>>> Thanks, >>>>> L-A >>>>> >>>>> >>>>> >>>>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>>>> Hello Nicolas, >>>>>> >>>>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>>>> >>>>>>> Hi Greg, >>>>>>> >>>>>>> I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for. >>>>>>> >>>>>>> Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. >>>>>> This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing. >>>>>> >>>>>> You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process. >>>>>> >>>>>> If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional. >>>>>> >>>>>> >>>>>>> Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. >>>>>> This is a good approach. >>>>>> >>>>>>> Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? >>>>>> Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know. >>>>>> >>>>>> The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by: >>>>>> >>>>>> %sh run_community.sh >>>>>> >>>>>> Feel free to ask questions! >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Nico >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------- >>>>>>> Nicolas Delhomme >>>>>>> >>>>>>> Genome Biology Computational Support >>>>>>> >>>>>>> European Molecular Biology Laboratory >>>>>>> >>>>>>> Tel: +49 6221 387 8310 >>>>>>> Email: nicolas.delhomme@embl.de >>>>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>>>> 69102 Heidelberg, Germany >>>>>>> --------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ___________________________________________________________ >>>>>>> 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/ >>>>>> Greg Von Kuster >>>>>> Galaxy Development Team >>>>>> greg@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/ >>>>> >>>> Greg Von Kuster >>>> Galaxy Development Team >>>> greg@bx.psu.edu >>>> >>>> >>>> >>> >>> <community_wsgi.ini><run_community.sh>___________________________________________________________ >>> 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/ >> >> Greg Von Kuster >> Galaxy Development Team >> greg@bx.psu.edu >> >> >> >
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Thanks for all the time you've been spending on it. Here is the config file for the toolshed: http://pastebin.com/2ckCTqUa And here is the config file for Galaxy: http://pastebin.com/0FrzZsB4 Hoping it helps :) L-A Le 25/11/2011 17:21, Greg Von Kuster a écrit :
Apache front-ends are not my area of expertise ( Nate may be needed for this ), but if you send me your apache settings that your use for Galaxy, I may be able to help. The tool shed uses the same static files as Galaxy, so they should be fine. Possibly the only issue is rewrites for new paths (although again, I'm not very knowledgable on apache with regard to rewrites). Here are the routes used in the tool shed if this helps.
webapp.add_route( '/:controller/:action', action='index' ) webapp.add_route( '/:action', controller='repository', action='index' ) webapp.add_route( '/repos/*path_info', controller='hg', action='handle_request', path_info='/' )
On Nov 25, 2011, at 11:00 AM, Louise-Amélie Schmitt wrote:
Woohoo thanks a lot, it works! :)
Well almost, but at least we have something displayed. I guess there are some rewriterules missing (or just plain wrong) in our apache config file: No css or image are used and we get this error:
Not Found
The requested URL /repository/browse_categories was not found on this server.
Here are the rules:
RewriteEngine on RewriteRule ^/toolshed$ /toolshed/ [R] RewriteRule ^/toolshed/static/style/(.*) /home/galaxy/galaxy-dev/static/june_2007_style/blue/$1 [L] RewriteRule ^/toolshed/static/(.*) /home/galaxy/galaxy-dev/static/$1 [L] RewriteRule ^/toolshed/images/(.*) /home/galaxy/galaxy-dev/static/images/$1 [L] RewriteRule ^/toolshed/upload/(.*) /home/galaxy/galaxy-dev/static/automated_upload/$1 [L] RewriteRule ^/toolshed/favicon.ico /home/galaxy/galaxy-dev/static/favicon.ico [L] RewriteRule ^/toolshed/robots.txt /home/galaxy/galaxy-dev/static/robots.txt [L] RewriteRule ^/toolshed(.*) http://localhost:9009$1 [P]
I kinda guessed them from what we had for galaxy, but most likely completely failed at it... Maybe you could give us some guidelines for the toolshed apache config file, like there is for galaxy in the wiki?
Thanks, L-A
Le 25/11/2011 16:44, Greg Von Kuster a écrit :
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help!
# Force everyone to log in (disable anonymous access) require_login = True
On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit : > That symlink should not be necessary. Can you remove it and > send me the complete paste log when you attempt to start your > tool shed server? > > On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote: > >> Hello Greg, >> >> This is precisely because we got the error that I added that >> section, like I mentioned earlier, but it didn't change >> anything. I will remove it again then. >> >> Do you have any other idea that we could explore? Do you need >> other files? >> >> Ah, I forgot to mention that at first start, it would complain >> about missing files so we created a symlink: >> ln -s <galaxy_home>/templates/webapps/community >> <galaxy_home>/lib/galaxy/webapps/community/templates >> >> Thanks, >> L-A >> >> >> >> Le 25/11/2011 14:07, Greg Von Kuster a écrit : >>> Hello Louise-Amelie, >>> >>> I believe the problem is caused by the inclusion of the >>> following settings in your community_webapp.ini file. This >>> sections should not be included in the tool shed config, so if >>> you remove it things should work. Let me know if you bump >>> into other issues. I apologize for the difficulty you've had >>> in getting your own local tool shed up and running. The tool >>> shed wiki currently focuses on using the Galaxy public tool >>> sheds, so I'll next add a section providing details for >>> setting up your own. >>> >>> # -- Display sites >>> >>> # Galaxy can display data at various external browsers. These >>> options specify >>> # which browsers should be available. URLs and builds >>> available at these >>> # browsers are defined in the specifield files. >>> >>> # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt >>> ucsc_display_sites = main,test,archaea,ucla >>> >>> # GBrowse servers: >>> tool-data/shared/gbrowse/gbrowse_build_sites.txt >>> gbrowse_display_sites = >>> wormbase,tair,modencode_worm,modencode_fly,yeast_sgd >>> >>> # GeneTrack servers: >>> tool-data/shared/genetrack/genetrack_sites.txt >>> genetrack_display_sites = main,test >>> >>> >>> On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote: >>> >>>> Hello Greg >>>> >>>> Please find attached the file you asked for. Just in case, I >>>> also sent you the run_community.sh script we use to start the >>>> toolshed. >>>> >>>> Thanks a lot, >>>> Louise-Amélie >>>> >>>> >>>> Le 25/11/2011 00:36, Greg Von Kuster a écrit : >>>>> Hello Louise, >>>>> >>>>> Can you send me your community_wsgi.ini file? I assume your >>>>> copied it from community_wsgi.ini.sample, but somehow it >>>>> looks like your configuration settings are attempting to >>>>> start the Galaxy server instead of the tool shed server. I >>>>> should be able to sort it out for you by looking at your >>>>> configuration file. >>>>> >>>>> Thanks, >>>>> >>>>> Greg Von Kuster >>>>> >>>>> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >>>>> >>>>>> Hello Greg >>>>>> >>>>>> We tried to run the toolshed like you explained (thanks a >>>>>> lot for the quick answer btw), it starts fine, but when we >>>>>> try to access it on the web, we get this error in the browser: >>>>>> >>>>>> Server Error >>>>>> An error occurred. See the error logs for more information. >>>>>> (Turn debug on to display exception reports here) >>>>>> >>>>>> In the logs, here is what we get: >>>>>> >>>>>> Error -<type 'exceptions.AttributeError'>: 'Configuration' >>>>>> object has no attribute 'ucsc_display_sites' >>>>>> URL: http://taiji/ >>>>>> File >>>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', >>>>>> line 143 in __call__ >>>>>> app_iter = self.application(environ, start_response) >>>>>> File >>>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', >>>>>> line 80 in __call__ >>>>>> return self.application(environ, start_response) >>>>>> File >>>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', >>>>>> line 632 in __call__ >>>>>> return self.application(environ, start_response) >>>>>> File >>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', >>>>>> line 134 in __call__ >>>>>> trans = self.transaction_factory( environ ) >>>>>> File >>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>>> line 187 in<lambda> >>>>>> self.set_transaction_factory( lambda e: >>>>>> self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>>>>> File >>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>>> line 207 in transaction_chooser >>>>>> return GalaxyWebUITransaction( environ, galaxy_app, self, >>>>>> session_cookie ) >>>>>> File >>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>>> line 860 in __init__ >>>>>> self._ensure_logged_in_user( environ ) >>>>>> File >>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>>> line 420 in _ensure_logged_in_user >>>>>> if self.app.config.ucsc_display_sites and self.request.path >>>>>> == display_as: >>>>>> AttributeError: 'Configuration' object has no attribute >>>>>> 'ucsc_display_sites' >>>>>> >>>>>> Since this name ringed a bell, I checked the >>>>>> universe_wsgi.ini and found this "Display sites" section. I >>>>>> therefore copied it and pasted it in the community.wsgi.ini >>>>>> file and uncommented the variables in this section. But >>>>>> when we tried again, we still get the same error. >>>>>> >>>>>> What is confusing, is that after the error message, all the >>>>>> CGI, congifuration and WSGI variables are displayed, and in >>>>>> the configuration section we have this line: >>>>>> ucsc_display_sites: 'main,test,archaea,ucla' >>>>>> >>>>>> Did we miss anything? Where should we start searching for a >>>>>> possible error source? >>>>>> >>>>>> Thanks, >>>>>> L-A >>>>>> >>>>>> >>>>>> >>>>>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>>>>> Hello Nicolas, >>>>>>> >>>>>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>>>>> >>>>>>>> Hi Greg, >>>>>>>> >>>>>>>> I've been scanning the mailing list, but wasn't lucky >>>>>>>> enough to find the answer I was looking for. >>>>>>>> >>>>>>>> Basically, we would be interested to have our own Galaxy >>>>>>>> Tool Shed in-house, to develop and test tools within our >>>>>>>> local Galaxy instance. What I'm thinking of, is to use >>>>>>>> the power of the tool shed to develop new algorithm, new >>>>>>>> tools, etc. that could be published afterwards. >>>>>>> This is great, but keep in mind that the intent of the >>>>>>> tool shed (whether it is a local, proprietary tool shed or >>>>>>> the public Galaxy tool shed) is to provide a vehicle for >>>>>>> sharing tools (and tool-related objects like workflows, >>>>>>> data types, etc) that are determined to be functional >>>>>>> within a Galaxy instance. So the primary use of a tool >>>>>>> shed should be to enable sharing. The tools themselves >>>>>>> should be implemented within a development environment >>>>>>> that includes a Galaxy instance, and when a tool is deemed >>>>>>> functional, it can then be uploaded to the tool shed for >>>>>>> sharing. >>>>>>> >>>>>>> You can, however, tweak the primary intent of a tool shed >>>>>>> to meet your needs. In your case, it seems that you may >>>>>>> be interested in using a local tool shed instance to share >>>>>>> tools between developers during the development process. >>>>>>> If this is the case, then your approach can be one where >>>>>>> a developer creates a repository on the local tool shed >>>>>>> multiple developers can clone it. The mercurial command >>>>>>> line process for committing, pushing, pulling and updating >>>>>>> can be used to share updates to the tool code by multiple >>>>>>> developers throughout the process. >>>>>>> >>>>>>> If a single developer is implementing the tool however, it >>>>>>> may make more sense to not use the tool shed as part of >>>>>>> the development process - just upload the tool when it is >>>>>>> functional. >>>>>>> >>>>>>> >>>>>>>> Because these would be sensitive material, we would not >>>>>>>> want to put them right away on the public test Tool Shed. >>>>>>>> Having a local Tool Shed instance would still be very >>>>>>>> helpful in releasing these tools to the community >>>>>>>> afterwards, as they would have been integrated and >>>>>>>> developed within that framework from the start. >>>>>>> This is a good approach. >>>>>>> >>>>>>>> Any pointers on how to achieve this are welcome as I'm >>>>>>>> not so familiar with the Tool Shed yet, e.g. would making >>>>>>>> a local clone of the tool shed repository be enough? >>>>>>> Make sure to read the tool shed wiki at >>>>>>> http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to >>>>>>> keep this up-to-date with the latest features of the tool >>>>>>> shed. You'll ffind, however, that there are some tool >>>>>>> shed admin user features that have not yet been >>>>>>> documented. If you have any question, let me know. >>>>>>> >>>>>>> The tool shed is included in the Galaxy distribution, so >>>>>>> no additional cloning is necessary - it is just a >>>>>>> different webpp from Galaxy itself. It uses a different >>>>>>> database from Galaxy, which you configure in the file >>>>>>> community_wsgi.ini (the equivalent of universe_wsgi.ini >>>>>>> for Galxy). After you have the configuration settings as >>>>>>> you want them, start up your local tool shed by: >>>>>>> >>>>>>> %sh run_community.sh >>>>>>> >>>>>>> Feel free to ask questions! >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Nico >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> Nicolas Delhomme >>>>>>>> >>>>>>>> Genome Biology Computational Support >>>>>>>> >>>>>>>> European Molecular Biology Laboratory >>>>>>>> >>>>>>>> Tel: +49 6221 387 8310 >>>>>>>> Email: nicolas.delhomme@embl.de >>>>>>>> <mailto:nicolas.delhomme@embl.de> >>>>>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>>>>> 69102 Heidelberg, Germany >>>>>>>> --------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ___________________________________________________________ >>>>>>>> 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/ >>>>>>> Greg Von Kuster >>>>>>> Galaxy Development Team >>>>>>> greg@bx.psu.edu <mailto:greg@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/ >>>>>> >>>>> Greg Von Kuster >>>>> Galaxy Development Team >>>>> greg@bx.psu.edu <mailto:greg@bx.psu.edu> >>>>> >>>>> >>>>> >>>> >>>> <community_wsgi.ini><run_community.sh>___________________________________________________________ >>>> 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/ >>> >>> Greg Von Kuster >>> Galaxy Development Team >>> greg@bx.psu.edu <mailto:greg@bx.psu.edu> >>> >>> >>> >> > > Greg Von Kuster > Galaxy Development Team > greg@bx.psu.edu <mailto:greg@bx.psu.edu> > > >
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
I won't be able to help on this - it's just not in my area of expertise ( your rewrite rules look logical to me ). I'll alert Nate to this issue next week. Just a "shot in the dark", do you have the following set the same in both your universe_wsgi.ini file for Galaxy and you community_wsgi.ini file for your tool shed? I'm not sure if these are used since you are using apache, but just want to make sure. # Serving static files (needed if running standalone) static_enabled = True static_cache_time = 360 static_dir = %(here)s/static/ static_images_dir = %(here)s/static/images static_favicon_dir = %(here)s/static/favicon.ico static_scripts_dir = %(here)s/static/scripts/ static_style_dir = %(here)s/static/june_2007_style/blue On Nov 25, 2011, at 12:01 PM, Louise-Amélie Schmitt wrote:
Thanks for all the time you've been spending on it.
Here is the config file for the toolshed: http://pastebin.com/2ckCTqUa
And here is the config file for Galaxy: http://pastebin.com/0FrzZsB4
Hoping it helps :) L-A
Le 25/11/2011 17:21, Greg Von Kuster a écrit :
Apache front-ends are not my area of expertise ( Nate may be needed for this ), but if you send me your apache settings that your use for Galaxy, I may be able to help. The tool shed uses the same static files as Galaxy, so they should be fine. Possibly the only issue is rewrites for new paths (although again, I'm not very knowledgable on apache with regard to rewrites). Here are the routes used in the tool shed if this helps.
webapp.add_route( '/:controller/:action', action='index' ) webapp.add_route( '/:action', controller='repository', action='index' ) webapp.add_route( '/repos/*path_info', controller='hg', action='handle_request', path_info='/' )
On Nov 25, 2011, at 11:00 AM, Louise-Amélie Schmitt wrote:
Woohoo thanks a lot, it works! :)
Well almost, but at least we have something displayed. I guess there are some rewriterules missing (or just plain wrong) in our apache config file: No css or image are used and we get this error: Not Found
The requested URL /repository/browse_categories was not found on this server. Here are the rules:
RewriteEngine on RewriteRule ^/toolshed$ /toolshed/ [R] RewriteRule ^/toolshed/static/style/(.*) /home/galaxy/galaxy-dev/static/june_2007_style/blue/$1 [L] RewriteRule ^/toolshed/static/(.*) /home/galaxy/galaxy-dev/static/$1 [L] RewriteRule ^/toolshed/images/(.*) /home/galaxy/galaxy-dev/static/images/$1 [L] RewriteRule ^/toolshed/upload/(.*) /home/galaxy/galaxy-dev/static/automated_upload/$1 [L] RewriteRule ^/toolshed/favicon.ico /home/galaxy/galaxy-dev/static/favicon.ico [L] RewriteRule ^/toolshed/robots.txt /home/galaxy/galaxy-dev/static/robots.txt [L] RewriteRule ^/toolshed(.*) http://localhost:9009$1 [P]
I kinda guessed them from what we had for galaxy, but most likely completely failed at it... Maybe you could give us some guidelines for the toolshed apache config file, like there is for galaxy in the wiki?
Thanks, L-A
Le 25/11/2011 16:44, Greg Von Kuster a écrit :
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help!
# Force everyone to log in (disable anonymous access) require_login = True
On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
> Here is the full log: > http://pastebin.com/qvB6UqxF > > > Le 25/11/2011 14:33, Greg Von Kuster a écrit : >> >> That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server? >> >> On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote: >> >>> Hello Greg, >>> >>> This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then. >>> >>> Do you have any other idea that we could explore? Do you need other files? >>> >>> Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: >>> ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates >>> >>> Thanks, >>> L-A >>> >>> >>> >>> Le 25/11/2011 14:07, Greg Von Kuster a écrit : >>>> >>>> Hello Louise-Amelie, >>>> >>>> I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own. >>>> >>>> # -- Display sites >>>> >>>> # Galaxy can display data at various external browsers. These options specify >>>> # which browsers should be available. URLs and builds available at these >>>> # browsers are defined in the specifield files. >>>> >>>> # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt >>>> ucsc_display_sites = main,test,archaea,ucla >>>> >>>> # GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt >>>> gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd >>>> >>>> # GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt >>>> genetrack_display_sites = main,test >>>> >>>> >>>> On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote: >>>> >>>>> Hello Greg >>>>> >>>>> Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed. >>>>> >>>>> Thanks a lot, >>>>> Louise-Amélie >>>>> >>>>> >>>>> Le 25/11/2011 00:36, Greg Von Kuster a écrit : >>>>>> Hello Louise, >>>>>> >>>>>> Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Greg Von Kuster >>>>>> >>>>>> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >>>>>> >>>>>>> Hello Greg >>>>>>> >>>>>>> We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser: >>>>>>> >>>>>>> Server Error >>>>>>> An error occurred. See the error logs for more information. (Turn debug on to display exception reports here) >>>>>>> >>>>>>> In the logs, here is what we get: >>>>>>> >>>>>>> Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' >>>>>>> URL: http://taiji/ >>>>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ >>>>>>> app_iter = self.application(environ, start_response) >>>>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ >>>>>>> return self.application(environ, start_response) >>>>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ >>>>>>> return self.application(environ, start_response) >>>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ >>>>>>> trans = self.transaction_factory( environ ) >>>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> >>>>>>> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser >>>>>>> return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) >>>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ >>>>>>> self._ensure_logged_in_user( environ ) >>>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user >>>>>>> if self.app.config.ucsc_display_sites and self.request.path == display_as: >>>>>>> AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites' >>>>>>> >>>>>>> Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error. >>>>>>> >>>>>>> What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: >>>>>>> ucsc_display_sites: 'main,test,archaea,ucla' >>>>>>> >>>>>>> Did we miss anything? Where should we start searching for a possible error source? >>>>>>> >>>>>>> Thanks, >>>>>>> L-A >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>>>>>> Hello Nicolas, >>>>>>>> >>>>>>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>>>>>> >>>>>>>>> Hi Greg, >>>>>>>>> >>>>>>>>> I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for. >>>>>>>>> >>>>>>>>> Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. >>>>>>>> This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing. >>>>>>>> >>>>>>>> You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process. >>>>>>>> >>>>>>>> If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional. >>>>>>>> >>>>>>>> >>>>>>>>> Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. >>>>>>>> This is a good approach. >>>>>>>> >>>>>>>>> Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? >>>>>>>> Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know. >>>>>>>> >>>>>>>> The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by: >>>>>>>> >>>>>>>> %sh run_community.sh >>>>>>>> >>>>>>>> Feel free to ask questions! >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Nico >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> Nicolas Delhomme >>>>>>>>> >>>>>>>>> Genome Biology Computational Support >>>>>>>>> >>>>>>>>> European Molecular Biology Laboratory >>>>>>>>> >>>>>>>>> Tel: +49 6221 387 8310 >>>>>>>>> Email: nicolas.delhomme@embl.de >>>>>>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>>>>>> 69102 Heidelberg, Germany >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ___________________________________________________________ >>>>>>>>> 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/ >>>>>>>> Greg Von Kuster >>>>>>>> Galaxy Development Team >>>>>>>> greg@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/ >>>>>>> >>>>>> Greg Von Kuster >>>>>> Galaxy Development Team >>>>>> greg@bx.psu.edu >>>>>> >>>>>> >>>>>> >>>>> >>>>> <community_wsgi.ini><run_community.sh>___________________________________________________________ >>>>> 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/ >>>> >>>> Greg Von Kuster >>>> Galaxy Development Team >>>> greg@bx.psu.edu >>>> >>>> >>>> >>> >> >> Greg Von Kuster >> Galaxy Development Team >> greg@bx.psu.edu >> >> >> >
Greg Von Kuster Galaxy Development Team greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Yes, they are all set the same. Thanks for all your precious help anyway, and have a good weekend :) Le 25/11/2011 18:36, Greg Von Kuster a écrit :
I won't be able to help on this - it's just not in my area of expertise ( your rewrite rules look logical to me ). I'll alert Nate to this issue next week. Just a "shot in the dark", do you have the following set the same in both your universe_wsgi.ini file for Galaxy and you community_wsgi.ini file for your tool shed? I'm not sure if these are used since you are using apache, but just want to make sure.
# Serving static files (needed if running standalone) static_enabled = True static_cache_time = 360 static_dir = %(here)s/static/ static_images_dir = %(here)s/static/images static_favicon_dir = %(here)s/static/favicon.ico static_scripts_dir = %(here)s/static/scripts/ static_style_dir = %(here)s/static/june_2007_style/blue
On Nov 25, 2011, at 12:01 PM, Louise-Amélie Schmitt wrote:
Thanks for all the time you've been spending on it.
Here is the config file for the toolshed: http://pastebin.com/2ckCTqUa
And here is the config file for Galaxy: http://pastebin.com/0FrzZsB4
Hoping it helps :) L-A
Le 25/11/2011 17:21, Greg Von Kuster a écrit :
Apache front-ends are not my area of expertise ( Nate may be needed for this ), but if you send me your apache settings that your use for Galaxy, I may be able to help. The tool shed uses the same static files as Galaxy, so they should be fine. Possibly the only issue is rewrites for new paths (although again, I'm not very knowledgable on apache with regard to rewrites). Here are the routes used in the tool shed if this helps.
webapp.add_route( '/:controller/:action', action='index' ) webapp.add_route( '/:action', controller='repository', action='index' ) webapp.add_route( '/repos/*path_info', controller='hg', action='handle_request', path_info='/' )
On Nov 25, 2011, at 11:00 AM, Louise-Amélie Schmitt wrote:
Woohoo thanks a lot, it works! :)
Well almost, but at least we have something displayed. I guess there are some rewriterules missing (or just plain wrong) in our apache config file: No css or image are used and we get this error:
Not Found
The requested URL /repository/browse_categories was not found on this server.
Here are the rules:
RewriteEngine on RewriteRule ^/toolshed$ /toolshed/ [R] RewriteRule ^/toolshed/static/style/(.*) /home/galaxy/galaxy-dev/static/june_2007_style/blue/$1 [L] RewriteRule ^/toolshed/static/(.*) /home/galaxy/galaxy-dev/static/$1 [L] RewriteRule ^/toolshed/images/(.*) /home/galaxy/galaxy-dev/static/images/$1 [L] RewriteRule ^/toolshed/upload/(.*) /home/galaxy/galaxy-dev/static/automated_upload/$1 [L] RewriteRule ^/toolshed/favicon.ico /home/galaxy/galaxy-dev/static/favicon.ico [L] RewriteRule ^/toolshed/robots.txt /home/galaxy/galaxy-dev/static/robots.txt [L] RewriteRule ^/toolshed(.*) http://localhost:9009$1 [P]
I kinda guessed them from what we had for galaxy, but most likely completely failed at it... Maybe you could give us some guidelines for the toolshed apache config file, like there is for galaxy in the wiki?
Thanks, L-A
Le 25/11/2011 16:44, Greg Von Kuster a écrit :
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help!
# Force everyone to log in (disable anonymous access) require_login = True
On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit : > Louise-Amelie, > > The following setting is incorrectly included in > community_wsgi.ini.sample - I've removed it in the latest change > set. I missed the setting in your community_wsgi.ini file - it > should be removed from there as well, and I think things will > work. I apologize for this - there have been many changes to > the config over the course of building the tool shed, and I > obviously missed removing this old setting that is no longer > used ( and, in fact now breaks things as we've found out ). > Very sorry for the inconvenience. > > # Where templates are stored > template_path = lib/galaxy/webapps/community/templates > > > On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote: > >> Here is the full log: >> http://pastebin.com/qvB6UqxF >> >> >> Le 25/11/2011 14:33, Greg Von Kuster a écrit : >>> That symlink should not be necessary. Can you remove it and >>> send me the complete paste log when you attempt to start your >>> tool shed server? >>> >>> On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote: >>> >>>> Hello Greg, >>>> >>>> This is precisely because we got the error that I added that >>>> section, like I mentioned earlier, but it didn't change >>>> anything. I will remove it again then. >>>> >>>> Do you have any other idea that we could explore? Do you need >>>> other files? >>>> >>>> Ah, I forgot to mention that at first start, it would >>>> complain about missing files so we created a symlink: >>>> ln -s <galaxy_home>/templates/webapps/community >>>> <galaxy_home>/lib/galaxy/webapps/community/templates >>>> >>>> Thanks, >>>> L-A >>>> >>>> >>>> >>>> Le 25/11/2011 14:07, Greg Von Kuster a écrit : >>>>> Hello Louise-Amelie, >>>>> >>>>> I believe the problem is caused by the inclusion of the >>>>> following settings in your community_webapp.ini file. This >>>>> sections should not be included in the tool shed config, so >>>>> if you remove it things should work. Let me know if you >>>>> bump into other issues. I apologize for the difficulty >>>>> you've had in getting your own local tool shed up and >>>>> running. The tool shed wiki currently focuses on using the >>>>> Galaxy public tool sheds, so I'll next add a section >>>>> providing details for setting up your own. >>>>> >>>>> # -- Display sites >>>>> >>>>> # Galaxy can display data at various external browsers. >>>>> These options specify >>>>> # which browsers should be available. URLs and builds >>>>> available at these >>>>> # browsers are defined in the specifield files. >>>>> >>>>> # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt >>>>> ucsc_display_sites = main,test,archaea,ucla >>>>> >>>>> # GBrowse servers: >>>>> tool-data/shared/gbrowse/gbrowse_build_sites.txt >>>>> gbrowse_display_sites = >>>>> wormbase,tair,modencode_worm,modencode_fly,yeast_sgd >>>>> >>>>> # GeneTrack servers: >>>>> tool-data/shared/genetrack/genetrack_sites.txt >>>>> genetrack_display_sites = main,test >>>>> >>>>> >>>>> On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote: >>>>> >>>>>> Hello Greg >>>>>> >>>>>> Please find attached the file you asked for. Just in case, >>>>>> I also sent you the run_community.sh script we use to start >>>>>> the toolshed. >>>>>> >>>>>> Thanks a lot, >>>>>> Louise-Amélie >>>>>> >>>>>> >>>>>> Le 25/11/2011 00:36, Greg Von Kuster a écrit : >>>>>>> Hello Louise, >>>>>>> >>>>>>> Can you send me your community_wsgi.ini file? I assume >>>>>>> your copied it from community_wsgi.ini.sample, but somehow >>>>>>> it looks like your configuration settings are attempting >>>>>>> to start the Galaxy server instead of the tool shed >>>>>>> server. I should be able to sort it out for you by >>>>>>> looking at your configuration file. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Greg Von Kuster >>>>>>> >>>>>>> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >>>>>>> >>>>>>>> Hello Greg >>>>>>>> >>>>>>>> We tried to run the toolshed like you explained (thanks a >>>>>>>> lot for the quick answer btw), it starts fine, but when >>>>>>>> we try to access it on the web, we get this error in the >>>>>>>> browser: >>>>>>>> >>>>>>>> Server Error >>>>>>>> An error occurred. See the error logs for more >>>>>>>> information. (Turn debug on to display exception reports >>>>>>>> here) >>>>>>>> >>>>>>>> In the logs, here is what we get: >>>>>>>> >>>>>>>> Error -<type 'exceptions.AttributeError'>: >>>>>>>> 'Configuration' object has no attribute 'ucsc_display_sites' >>>>>>>> URL: http://taiji/ >>>>>>>> File >>>>>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', >>>>>>>> line 143 in __call__ >>>>>>>> app_iter = self.application(environ, start_response) >>>>>>>> File >>>>>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', >>>>>>>> line 80 in __call__ >>>>>>>> return self.application(environ, start_response) >>>>>>>> File >>>>>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', >>>>>>>> line 632 in __call__ >>>>>>>> return self.application(environ, start_response) >>>>>>>> File >>>>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', >>>>>>>> line 134 in __call__ >>>>>>>> trans = self.transaction_factory( environ ) >>>>>>>> File >>>>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>>>>> line 187 in<lambda> >>>>>>>> self.set_transaction_factory( lambda e: >>>>>>>> self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>>>>>>> File >>>>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>>>>> line 207 in transaction_chooser >>>>>>>> return GalaxyWebUITransaction( environ, galaxy_app, self, >>>>>>>> session_cookie ) >>>>>>>> File >>>>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>>>>> line 860 in __init__ >>>>>>>> self._ensure_logged_in_user( environ ) >>>>>>>> File >>>>>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>>>>> line 420 in _ensure_logged_in_user >>>>>>>> if self.app.config.ucsc_display_sites and >>>>>>>> self.request.path == display_as: >>>>>>>> AttributeError: 'Configuration' object has no attribute >>>>>>>> 'ucsc_display_sites' >>>>>>>> >>>>>>>> Since this name ringed a bell, I checked the >>>>>>>> universe_wsgi.ini and found this "Display sites" section. >>>>>>>> I therefore copied it and pasted it in the >>>>>>>> community.wsgi.ini file and uncommented the variables in >>>>>>>> this section. But when we tried again, we still get the >>>>>>>> same error. >>>>>>>> >>>>>>>> What is confusing, is that after the error message, all >>>>>>>> the CGI, congifuration and WSGI variables are displayed, >>>>>>>> and in the configuration section we have this line: >>>>>>>> ucsc_display_sites: 'main,test,archaea,ucla' >>>>>>>> >>>>>>>> Did we miss anything? Where should we start searching for >>>>>>>> a possible error source? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> L-A >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>>>>>>> Hello Nicolas, >>>>>>>>> >>>>>>>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>>>>>>> >>>>>>>>>> Hi Greg, >>>>>>>>>> >>>>>>>>>> I've been scanning the mailing list, but wasn't lucky >>>>>>>>>> enough to find the answer I was looking for. >>>>>>>>>> >>>>>>>>>> Basically, we would be interested to have our own >>>>>>>>>> Galaxy Tool Shed in-house, to develop and test tools >>>>>>>>>> within our local Galaxy instance. What I'm thinking of, >>>>>>>>>> is to use the power of the tool shed to develop new >>>>>>>>>> algorithm, new tools, etc. that could be published >>>>>>>>>> afterwards. >>>>>>>>> This is great, but keep in mind that the intent of the >>>>>>>>> tool shed (whether it is a local, proprietary tool shed >>>>>>>>> or the public Galaxy tool shed) is to provide a vehicle >>>>>>>>> for sharing tools (and tool-related objects like >>>>>>>>> workflows, data types, etc) that are determined to be >>>>>>>>> functional within a Galaxy instance. So the primary use >>>>>>>>> of a tool shed should be to enable sharing. The tools >>>>>>>>> themselves should be implemented within a development >>>>>>>>> environment that includes a Galaxy instance, and when a >>>>>>>>> tool is deemed functional, it can then be uploaded to >>>>>>>>> the tool shed for sharing. >>>>>>>>> >>>>>>>>> You can, however, tweak the primary intent of a tool >>>>>>>>> shed to meet your needs. In your case, it seems that >>>>>>>>> you may be interested in using a local tool shed >>>>>>>>> instance to share tools between developers during the >>>>>>>>> development process. If this is the case, then your >>>>>>>>> approach can be one where a developer creates a >>>>>>>>> repository on the local tool shed multiple developers >>>>>>>>> can clone it. The mercurial command line process for >>>>>>>>> committing, pushing, pulling and updating can be used to >>>>>>>>> share updates to the tool code by multiple developers >>>>>>>>> throughout the process. >>>>>>>>> >>>>>>>>> If a single developer is implementing the tool however, >>>>>>>>> it may make more sense to not use the tool shed as part >>>>>>>>> of the development process - just upload the tool when >>>>>>>>> it is functional. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Because these would be sensitive material, we would not >>>>>>>>>> want to put them right away on the public test Tool >>>>>>>>>> Shed. Having a local Tool Shed instance would still be >>>>>>>>>> very helpful in releasing these tools to the community >>>>>>>>>> afterwards, as they would have been integrated and >>>>>>>>>> developed within that framework from the start. >>>>>>>>> This is a good approach. >>>>>>>>> >>>>>>>>>> Any pointers on how to achieve this are welcome as I'm >>>>>>>>>> not so familiar with the Tool Shed yet, e.g. would >>>>>>>>>> making a local clone of the tool shed repository be enough? >>>>>>>>> Make sure to read the tool shed wiki at >>>>>>>>> http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to >>>>>>>>> keep this up-to-date with the latest features of the >>>>>>>>> tool shed. You'll ffind, however, that there are some >>>>>>>>> tool shed admin user features that have not yet been >>>>>>>>> documented. If you have any question, let me know. >>>>>>>>> >>>>>>>>> The tool shed is included in the Galaxy distribution, so >>>>>>>>> no additional cloning is necessary - it is just a >>>>>>>>> different webpp from Galaxy itself. It uses a different >>>>>>>>> database from Galaxy, which you configure in the file >>>>>>>>> community_wsgi.ini (the equivalent of universe_wsgi.ini >>>>>>>>> for Galxy). After you have the configuration settings >>>>>>>>> as you want them, start up your local tool shed by: >>>>>>>>> >>>>>>>>> %sh run_community.sh >>>>>>>>> >>>>>>>>> Feel free to ask questions! >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Nico >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>> Nicolas Delhomme >>>>>>>>>> >>>>>>>>>> Genome Biology Computational Support >>>>>>>>>> >>>>>>>>>> European Molecular Biology Laboratory >>>>>>>>>> >>>>>>>>>> Tel: +49 6221 387 8310 >>>>>>>>>> Email: nicolas.delhomme@embl.de >>>>>>>>>> <mailto:nicolas.delhomme@embl.de> >>>>>>>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>>>>>>> 69102 Heidelberg, Germany >>>>>>>>>> --------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ___________________________________________________________ >>>>>>>>>> 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/ >>>>>>>>> Greg Von Kuster >>>>>>>>> Galaxy Development Team >>>>>>>>> greg@bx.psu.edu <mailto:greg@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/ >>>>>>>> >>>>>>> Greg Von Kuster >>>>>>> Galaxy Development Team >>>>>>> greg@bx.psu.edu <mailto:greg@bx.psu.edu> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> <community_wsgi.ini><run_community.sh>___________________________________________________________ >>>>>> 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/ >>>>> >>>>> Greg Von Kuster >>>>> Galaxy Development Team >>>>> greg@bx.psu.edu <mailto:greg@bx.psu.edu> >>>>> >>>>> >>>>> >>>> >>> >>> Greg Von Kuster >>> Galaxy Development Team >>> greg@bx.psu.edu <mailto:greg@bx.psu.edu> >>> >>> >>> >> > > Greg Von Kuster > Galaxy Development Team > greg@bx.psu.edu <mailto:greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Hello Louise-Amelie, Please try adding the following config settings to your community_wsgi.ini file, and let me know if doing so corrects the problem> ============================= The following settings go somewhere outside of [app:main] # Define the proxy-prefix filter. [filter:proxy-prefix] use = egg:PasteDeploy#prefix prefix = /toolshed ============================= The following setting goes somewhere inside of [app:main] filter-with = proxy-prefix On Nov 25, 2011, at 12:45 PM, Louise-Amélie Schmitt wrote:
Well almost, but at least we have something displayed. I guess there are some rewriterules missing (or just plain wrong) in our apache config file: No css or image are used and we get this error: Not Found
The requested URL /repository/browse_categories was not found on this server. Here are the rules:
RewriteEngine on RewriteRule ^/toolshed$ /toolshed/ [R] RewriteRule ^/toolshed/static/style/(.*) /home/galaxy/galaxy-dev/static/june_2007_style/blue/$1 [L] RewriteRule ^/toolshed/static/(.*) /home/galaxy/galaxy-dev/static/$1 [L] RewriteRule ^/toolshed/images/(.*) /home/galaxy/galaxy-dev/static/images/$1 [L] RewriteRule ^/toolshed/upload/(.*) /home/galaxy/galaxy-dev/static/automated_upload/$1 [L] RewriteRule ^/toolshed/favicon.ico /home/galaxy/galaxy-dev/static/favicon.ico [L] RewriteRule ^/toolshed/robots.txt /home/galaxy/galaxy-dev/static/robots.txt [L] RewriteRule ^/toolshed(.*) http://localhost:9009$1 [P]
I kinda guessed them from what we had for galaxy, but most likely completely failed at it... Maybe you could give us some guidelines for the toolshed apache config file, like there is for galaxy in the wiki?
Thanks, L-A
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
IT WORKS!!! Thank you so much! :) Best, L-A Le 28/11/2011 16:48, Greg Von Kuster a écrit :
Hello Louise-Amelie,
Please try adding the following config settings to your community_wsgi.ini file, and let me know if doing so corrects the problem>
=============================
The following settings go somewhere outside of [app:main]
# Define the proxy-prefix filter. [filter:proxy-prefix]
use = egg:PasteDeploy#prefix prefix = /toolshed
=============================
The following setting goes somewhere inside of [app:main]
filter-with = proxy-prefix
On Nov 25, 2011, at 12:45 PM, Louise-Amélie Schmitt wrote:
Well almost, but at least we have something displayed. I guess there are some rewriterules missing (or just plain wrong) in our apache config file: No css or image are used and we get this error:
Not Found
The requested URL /repository/browse_categories was not found on this server.
Here are the rules:
RewriteEngine on RewriteRule ^/toolshed$ /toolshed/ [R] RewriteRule ^/toolshed/static/style/(.*) /home/galaxy/galaxy-dev/static/june_2007_style/blue/$1 [L] RewriteRule ^/toolshed/static/(.*) /home/galaxy/galaxy-dev/static/$1 [L] RewriteRule ^/toolshed/images/(.*) /home/galaxy/galaxy-dev/static/images/$1 [L] RewriteRule ^/toolshed/upload/(.*) /home/galaxy/galaxy-dev/static/automated_upload/$1 [L] RewriteRule ^/toolshed/favicon.ico /home/galaxy/galaxy-dev/static/favicon.ico [L] RewriteRule ^/toolshed/robots.txt /home/galaxy/galaxy-dev/static/robots.txt [L] RewriteRule ^/toolshed(.*) http://localhost:9009$1 [P]
I kinda guessed them from what we had for galaxy, but most likely completely failed at it... Maybe you could give us some guidelines for the toolshed apache config file, like there is for galaxy in the wiki?
Thanks, L-A
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
The fix for the following config setting in community_wsgi.ini is now available in change set 6339:5db0da0007fc in our central repo. require_login = True On Nov 25, 2011, at 10:44 AM, Greg Von Kuster wrote:
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help!
# Force everyone to log in (disable anonymous access) require_login = True
On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit :
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server?
On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
Hello Greg,
This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then.
Do you have any other idea that we could explore? Do you need other files?
Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates
Thanks, L-A
Le 25/11/2011 14:07, Greg Von Kuster a écrit : > > Hello Louise-Amelie, > > I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own. > > # -- Display sites > > # Galaxy can display data at various external browsers. These options specify > # which browsers should be available. URLs and builds available at these > # browsers are defined in the specifield files. > > # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt > ucsc_display_sites = main,test,archaea,ucla > > # GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt > gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd > > # GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt > genetrack_display_sites = main,test > > > On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote: > >> Hello Greg >> >> Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed. >> >> Thanks a lot, >> Louise-Amélie >> >> >> Le 25/11/2011 00:36, Greg Von Kuster a écrit : >>> Hello Louise, >>> >>> Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file. >>> >>> Thanks, >>> >>> Greg Von Kuster >>> >>> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >>> >>>> Hello Greg >>>> >>>> We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser: >>>> >>>> Server Error >>>> An error occurred. See the error logs for more information. (Turn debug on to display exception reports here) >>>> >>>> In the logs, here is what we get: >>>> >>>> Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' >>>> URL: http://taiji/ >>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ >>>> app_iter = self.application(environ, start_response) >>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ >>>> return self.application(environ, start_response) >>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ >>>> return self.application(environ, start_response) >>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ >>>> trans = self.transaction_factory( environ ) >>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> >>>> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser >>>> return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) >>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ >>>> self._ensure_logged_in_user( environ ) >>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user >>>> if self.app.config.ucsc_display_sites and self.request.path == display_as: >>>> AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites' >>>> >>>> Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error. >>>> >>>> What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: >>>> ucsc_display_sites: 'main,test,archaea,ucla' >>>> >>>> Did we miss anything? Where should we start searching for a possible error source? >>>> >>>> Thanks, >>>> L-A >>>> >>>> >>>> >>>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>>> Hello Nicolas, >>>>> >>>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>>> >>>>>> Hi Greg, >>>>>> >>>>>> I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for. >>>>>> >>>>>> Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. >>>>> This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing. >>>>> >>>>> You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process. >>>>> >>>>> If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional. >>>>> >>>>> >>>>>> Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. >>>>> This is a good approach. >>>>> >>>>>> Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? >>>>> Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know. >>>>> >>>>> The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by: >>>>> >>>>> %sh run_community.sh >>>>> >>>>> Feel free to ask questions! >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Nico >>>>>> >>>>>> >>>>>> --------------------------------------------------------------- >>>>>> Nicolas Delhomme >>>>>> >>>>>> Genome Biology Computational Support >>>>>> >>>>>> European Molecular Biology Laboratory >>>>>> >>>>>> Tel: +49 6221 387 8310 >>>>>> Email: nicolas.delhomme@embl.de >>>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>>> 69102 Heidelberg, Germany >>>>>> --------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ___________________________________________________________ >>>>>> 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/ >>>>> Greg Von Kuster >>>>> Galaxy Development Team >>>>> greg@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/ >>>> >>> Greg Von Kuster >>> Galaxy Development Team >>> greg@bx.psu.edu >>> >>> >>> >> >> <community_wsgi.ini><run_community.sh>___________________________________________________________ >> 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/ > > Greg Von Kuster > Galaxy Development Team > greg@bx.psu.edu > > >
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Greg Von Kuster Galaxy Development Team greg@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:
Greg Von Kuster Galaxy Development Team greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
Hey I have another issue for you! :) It's in the file lib/galaxy/webapps/community/controllers/repository.py For some reason, when the __add_hgweb_config_entry function tries to strip the repository_path from a possible leading './' it also removes the leading '/' in absolute paths. I could avoid the issue by commenting the code where './' are removed: 1032 def __add_hgweb_config_entry( self, trans, repository, repository_path ): 1033 # Add an entry in the hgweb.config file for a new repository. An entry looks something like: 1034 # repos/test/mira_assembler = database/community_files/000/repo_123. 1035 hgweb_config = "%s/hgweb.config" % trans.app.config.root 1036 #if repository_path.startswith( './' ): 1037 # repository_path = repository_path.replace( './', '', 1 ) 1038 entry = "repos/%s/%s = %s" % ( repository.user.username, repository.name, repository_path ) #.lstrip( './' ) ) 1039 tmp_fd, tmp_fname = tempfile.mkstemp() I'm really confused, but this seems to work for us. Hope that can help L-A Le 28/11/2011 22:33, Greg Von Kuster a écrit :
The fix for the following config setting in community_wsgi.ini is now available in change set 6339:5db0da0007fc in our central repo.
require_login = True
On Nov 25, 2011, at 10:44 AM, Greg Von Kuster wrote:
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help!
# Force everyone to log in (disable anonymous access) require_login = True
On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit :
That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server?
On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote:
> Hello Greg, > > This is precisely because we got the error that I added that > section, like I mentioned earlier, but it didn't change > anything. I will remove it again then. > > Do you have any other idea that we could explore? Do you need > other files? > > Ah, I forgot to mention that at first start, it would complain > about missing files so we created a symlink: > ln -s <galaxy_home>/templates/webapps/community > <galaxy_home>/lib/galaxy/webapps/community/templates > > Thanks, > L-A > > > > Le 25/11/2011 14:07, Greg Von Kuster a écrit : >> Hello Louise-Amelie, >> >> I believe the problem is caused by the inclusion of the >> following settings in your community_webapp.ini file. This >> sections should not be included in the tool shed config, so if >> you remove it things should work. Let me know if you bump into >> other issues. I apologize for the difficulty you've had in >> getting your own local tool shed up and running. The tool shed >> wiki currently focuses on using the Galaxy public tool sheds, >> so I'll next add a section providing details for setting up >> your own. >> >> # -- Display sites >> >> # Galaxy can display data at various external browsers. These >> options specify >> # which browsers should be available. URLs and builds >> available at these >> # browsers are defined in the specifield files. >> >> # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt >> ucsc_display_sites = main,test,archaea,ucla >> >> # GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt >> gbrowse_display_sites = >> wormbase,tair,modencode_worm,modencode_fly,yeast_sgd >> >> # GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt >> genetrack_display_sites = main,test >> >> >> On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote: >> >>> Hello Greg >>> >>> Please find attached the file you asked for. Just in case, I >>> also sent you the run_community.sh script we use to start the >>> toolshed. >>> >>> Thanks a lot, >>> Louise-Amélie >>> >>> >>> Le 25/11/2011 00:36, Greg Von Kuster a écrit : >>>> Hello Louise, >>>> >>>> Can you send me your community_wsgi.ini file? I assume your >>>> copied it from community_wsgi.ini.sample, but somehow it >>>> looks like your configuration settings are attempting to >>>> start the Galaxy server instead of the tool shed server. I >>>> should be able to sort it out for you by looking at your >>>> configuration file. >>>> >>>> Thanks, >>>> >>>> Greg Von Kuster >>>> >>>> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >>>> >>>>> Hello Greg >>>>> >>>>> We tried to run the toolshed like you explained (thanks a >>>>> lot for the quick answer btw), it starts fine, but when we >>>>> try to access it on the web, we get this error in the browser: >>>>> >>>>> Server Error >>>>> An error occurred. See the error logs for more information. >>>>> (Turn debug on to display exception reports here) >>>>> >>>>> In the logs, here is what we get: >>>>> >>>>> Error -<type 'exceptions.AttributeError'>: 'Configuration' >>>>> object has no attribute 'ucsc_display_sites' >>>>> URL: http://taiji/ >>>>> File >>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', >>>>> line 143 in __call__ >>>>> app_iter = self.application(environ, start_response) >>>>> File >>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', >>>>> line 80 in __call__ >>>>> return self.application(environ, start_response) >>>>> File >>>>> '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', >>>>> line 632 in __call__ >>>>> return self.application(environ, start_response) >>>>> File >>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', >>>>> line 134 in __call__ >>>>> trans = self.transaction_factory( environ ) >>>>> File >>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>> line 187 in<lambda> >>>>> self.set_transaction_factory( lambda e: >>>>> self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>>>> File >>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>> line 207 in transaction_chooser >>>>> return GalaxyWebUITransaction( environ, galaxy_app, self, >>>>> session_cookie ) >>>>> File >>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>> line 860 in __init__ >>>>> self._ensure_logged_in_user( environ ) >>>>> File >>>>> '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', >>>>> line 420 in _ensure_logged_in_user >>>>> if self.app.config.ucsc_display_sites and self.request.path >>>>> == display_as: >>>>> AttributeError: 'Configuration' object has no attribute >>>>> 'ucsc_display_sites' >>>>> >>>>> Since this name ringed a bell, I checked the >>>>> universe_wsgi.ini and found this "Display sites" section. I >>>>> therefore copied it and pasted it in the community.wsgi.ini >>>>> file and uncommented the variables in this section. But when >>>>> we tried again, we still get the same error. >>>>> >>>>> What is confusing, is that after the error message, all the >>>>> CGI, congifuration and WSGI variables are displayed, and in >>>>> the configuration section we have this line: >>>>> ucsc_display_sites: 'main,test,archaea,ucla' >>>>> >>>>> Did we miss anything? Where should we start searching for a >>>>> possible error source? >>>>> >>>>> Thanks, >>>>> L-A >>>>> >>>>> >>>>> >>>>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>>>> Hello Nicolas, >>>>>> >>>>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>>>> >>>>>>> Hi Greg, >>>>>>> >>>>>>> I've been scanning the mailing list, but wasn't lucky >>>>>>> enough to find the answer I was looking for. >>>>>>> >>>>>>> Basically, we would be interested to have our own Galaxy >>>>>>> Tool Shed in-house, to develop and test tools within our >>>>>>> local Galaxy instance. What I'm thinking of, is to use the >>>>>>> power of the tool shed to develop new algorithm, new >>>>>>> tools, etc. that could be published afterwards. >>>>>> This is great, but keep in mind that the intent of the tool >>>>>> shed (whether it is a local, proprietary tool shed or the >>>>>> public Galaxy tool shed) is to provide a vehicle for >>>>>> sharing tools (and tool-related objects like workflows, >>>>>> data types, etc) that are determined to be functional >>>>>> within a Galaxy instance. So the primary use of a tool >>>>>> shed should be to enable sharing. The tools themselves >>>>>> should be implemented within a development environment that >>>>>> includes a Galaxy instance, and when a tool is deemed >>>>>> functional, it can then be uploaded to the tool shed for >>>>>> sharing. >>>>>> >>>>>> You can, however, tweak the primary intent of a tool shed >>>>>> to meet your needs. In your case, it seems that you may be >>>>>> interested in using a local tool shed instance to share >>>>>> tools between developers during the development process. >>>>>> If this is the case, then your approach can be one where a >>>>>> developer creates a repository on the local tool shed >>>>>> multiple developers can clone it. The mercurial command >>>>>> line process for committing, pushing, pulling and updating >>>>>> can be used to share updates to the tool code by multiple >>>>>> developers throughout the process. >>>>>> >>>>>> If a single developer is implementing the tool however, it >>>>>> may make more sense to not use the tool shed as part of the >>>>>> development process - just upload the tool when it is >>>>>> functional. >>>>>> >>>>>> >>>>>>> Because these would be sensitive material, we would not >>>>>>> want to put them right away on the public test Tool Shed. >>>>>>> Having a local Tool Shed instance would still be very >>>>>>> helpful in releasing these tools to the community >>>>>>> afterwards, as they would have been integrated and >>>>>>> developed within that framework from the start. >>>>>> This is a good approach. >>>>>> >>>>>>> Any pointers on how to achieve this are welcome as I'm not >>>>>>> so familiar with the Tool Shed yet, e.g. would making a >>>>>>> local clone of the tool shed repository be enough? >>>>>> Make sure to read the tool shed wiki at >>>>>> http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep >>>>>> this up-to-date with the latest features of the tool shed. >>>>>> You'll ffind, however, that there are some tool shed admin >>>>>> user features that have not yet been documented. If you >>>>>> have any question, let me know. >>>>>> >>>>>> The tool shed is included in the Galaxy distribution, so no >>>>>> additional cloning is necessary - it is just a different >>>>>> webpp from Galaxy itself. It uses a different database >>>>>> from Galaxy, which you configure in the file >>>>>> community_wsgi.ini (the equivalent of universe_wsgi.ini for >>>>>> Galxy). After you have the configuration settings as you >>>>>> want them, start up your local tool shed by: >>>>>> >>>>>> %sh run_community.sh >>>>>> >>>>>> Feel free to ask questions! >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Nico >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------- >>>>>>> Nicolas Delhomme >>>>>>> >>>>>>> Genome Biology Computational Support >>>>>>> >>>>>>> European Molecular Biology Laboratory >>>>>>> >>>>>>> Tel: +49 6221 387 8310 >>>>>>> Email: nicolas.delhomme@embl.de >>>>>>> <mailto:nicolas.delhomme@embl.de> >>>>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>>>> 69102 Heidelberg, Germany >>>>>>> --------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ___________________________________________________________ >>>>>>> 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/ >>>>>> Greg Von Kuster >>>>>> Galaxy Development Team >>>>>> greg@bx.psu.edu <mailto:greg@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/ >>>>> >>>> Greg Von Kuster >>>> Galaxy Development Team >>>> greg@bx.psu.edu <mailto:greg@bx.psu.edu> >>>> >>>> >>>> >>> >>> <community_wsgi.ini><run_community.sh>___________________________________________________________ >>> 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/ >> >> Greg Von Kuster >> Galaxy Development Team >> greg@bx.psu.edu <mailto:greg@bx.psu.edu> >> >> >> >
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu <mailto:greg@bx.psu.edu>
Hello Louise-Amelie, Can you send me an example hgweb.config entry for which the strip is problematic? I cannot reproduce the problem. Also, using absolute paths in this file may cause problems as it results in very restrictive locations for the repositories. Why are you using absolute paths? Thanks! On Nov 30, 2011, at 12:01 PM, Louise-Amélie Schmitt wrote:
Hey I have another issue for you! :)
It's in the file lib/galaxy/webapps/community/controllers/repository.py
For some reason, when the __add_hgweb_config_entry function tries to strip the repository_path from a possible leading './' it also removes the leading '/' in absolute paths. I could avoid the issue by commenting the code where './' are removed:
1032 def __add_hgweb_config_entry( self, trans, repository, repository_path ): 1033 # Add an entry in the hgweb.config file for a new repository. An entry looks something like: 1034 # repos/test/mira_assembler = database/community_files/000/repo_123. 1035 hgweb_config = "%s/hgweb.config" % trans.app.config.root 1036 #if repository_path.startswith( './' ): 1037 # repository_path = repository_path.replace( './', '', 1 ) 1038 entry = "repos/%s/%s = %s" % ( repository.user.username, repository.name, repository_path ) #.lstrip( './' ) ) 1039 tmp_fd, tmp_fname = tempfile.mkstemp()
I'm really confused, but this seems to work for us.
Hope that can help L-A
Le 28/11/2011 22:33, Greg Von Kuster a écrit :
The fix for the following config setting in community_wsgi.ini is now available in change set 6339:5db0da0007fc in our central repo.
require_login = True
On Nov 25, 2011, at 10:44 AM, Greg Von Kuster wrote:
Set the following config setting in your community_wsgi.ini file to be False for now instead of True. There's a bug in the shared Galaxy code base that produces the problem you see. I'll get a fix in for this asap, but users are not required to login to use many of the features of the tool shed. Let me know if you find additional issues - you're the first to set up your own tool shed, so you're in the position of having to iron out issues like this. Thanks for all of your help!
# Force everyone to log in (disable anonymous access) require_login = True
On Nov 25, 2011, at 9:38 AM, Louise-Amélie Schmitt wrote:
Well, the symlink is indeed not needed anymore, thanks for the fix.
However, the original error still stands. Here is the full output: http://pastebin.com/K5r6wd0A
Hope that helps L-A
Le 25/11/2011 15:22, Greg Von Kuster a écrit :
Louise-Amelie,
The following setting is incorrectly included in community_wsgi.ini.sample - I've removed it in the latest change set. I missed the setting in your community_wsgi.ini file - it should be removed from there as well, and I think things will work. I apologize for this - there have been many changes to the config over the course of building the tool shed, and I obviously missed removing this old setting that is no longer used ( and, in fact now breaks things as we've found out ). Very sorry for the inconvenience.
# Where templates are stored template_path = lib/galaxy/webapps/community/templates
On Nov 25, 2011, at 8:48 AM, Louise-Amélie Schmitt wrote:
Here is the full log: http://pastebin.com/qvB6UqxF
Le 25/11/2011 14:33, Greg Von Kuster a écrit : > > That symlink should not be necessary. Can you remove it and send me the complete paste log when you attempt to start your tool shed server? > > On Nov 25, 2011, at 8:23 AM, Louise-Amélie Schmitt wrote: > >> Hello Greg, >> >> This is precisely because we got the error that I added that section, like I mentioned earlier, but it didn't change anything. I will remove it again then. >> >> Do you have any other idea that we could explore? Do you need other files? >> >> Ah, I forgot to mention that at first start, it would complain about missing files so we created a symlink: >> ln -s <galaxy_home>/templates/webapps/community <galaxy_home>/lib/galaxy/webapps/community/templates >> >> Thanks, >> L-A >> >> >> >> Le 25/11/2011 14:07, Greg Von Kuster a écrit : >>> >>> Hello Louise-Amelie, >>> >>> I believe the problem is caused by the inclusion of the following settings in your community_webapp.ini file. This sections should not be included in the tool shed config, so if you remove it things should work. Let me know if you bump into other issues. I apologize for the difficulty you've had in getting your own local tool shed up and running. The tool shed wiki currently focuses on using the Galaxy public tool sheds, so I'll next add a section providing details for setting up your own. >>> >>> # -- Display sites >>> >>> # Galaxy can display data at various external browsers. These options specify >>> # which browsers should be available. URLs and builds available at these >>> # browsers are defined in the specifield files. >>> >>> # UCSC browsers: tool-data/shared/ucsc/ucsc_build_sites.txt >>> ucsc_display_sites = main,test,archaea,ucla >>> >>> # GBrowse servers: tool-data/shared/gbrowse/gbrowse_build_sites.txt >>> gbrowse_display_sites = wormbase,tair,modencode_worm,modencode_fly,yeast_sgd >>> >>> # GeneTrack servers: tool-data/shared/genetrack/genetrack_sites.txt >>> genetrack_display_sites = main,test >>> >>> >>> On Nov 25, 2011, at 3:01 AM, Louise-Amélie Schmitt wrote: >>> >>>> Hello Greg >>>> >>>> Please find attached the file you asked for. Just in case, I also sent you the run_community.sh script we use to start the toolshed. >>>> >>>> Thanks a lot, >>>> Louise-Amélie >>>> >>>> >>>> Le 25/11/2011 00:36, Greg Von Kuster a écrit : >>>>> Hello Louise, >>>>> >>>>> Can you send me your community_wsgi.ini file? I assume your copied it from community_wsgi.ini.sample, but somehow it looks like your configuration settings are attempting to start the Galaxy server instead of the tool shed server. I should be able to sort it out for you by looking at your configuration file. >>>>> >>>>> Thanks, >>>>> >>>>> Greg Von Kuster >>>>> >>>>> On Nov 24, 2011, at 10:34 AM, Louise-Amélie Schmitt wrote: >>>>> >>>>>> Hello Greg >>>>>> >>>>>> We tried to run the toolshed like you explained (thanks a lot for the quick answer btw), it starts fine, but when we try to access it on the web, we get this error in the browser: >>>>>> >>>>>> Server Error >>>>>> An error occurred. See the error logs for more information. (Turn debug on to display exception reports here) >>>>>> >>>>>> In the logs, here is what we get: >>>>>> >>>>>> Error -<type 'exceptions.AttributeError'>: 'Configuration' object has no attribute 'ucsc_display_sites' >>>>>> URL: http://taiji/ >>>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/exceptions/errormiddleware.py', line 143 in __call__ >>>>>> app_iter = self.application(environ, start_response) >>>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/recursive.py', line 80 in __call__ >>>>>> return self.application(environ, start_response) >>>>>> File '/home/galaxy/galaxy-dev/eggs/Paste-1.6-py2.6.egg/paste/httpexceptions.py', line 632 in __call__ >>>>>> return self.application(environ, start_response) >>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/base.py', line 134 in __call__ >>>>>> trans = self.transaction_factory( environ ) >>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 187 in<lambda> >>>>>> self.set_transaction_factory( lambda e: self.transaction_chooser( e, galaxy_app, session_cookie ) ) >>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 207 in transaction_chooser >>>>>> return GalaxyWebUITransaction( environ, galaxy_app, self, session_cookie ) >>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 860 in __init__ >>>>>> self._ensure_logged_in_user( environ ) >>>>>> File '/home/galaxy/galaxy-dev/lib/galaxy/web/framework/__init__.py', line 420 in _ensure_logged_in_user >>>>>> if self.app.config.ucsc_display_sites and self.request.path == display_as: >>>>>> AttributeError: 'Configuration' object has no attribute 'ucsc_display_sites' >>>>>> >>>>>> Since this name ringed a bell, I checked the universe_wsgi.ini and found this "Display sites" section. I therefore copied it and pasted it in the community.wsgi.ini file and uncommented the variables in this section. But when we tried again, we still get the same error. >>>>>> >>>>>> What is confusing, is that after the error message, all the CGI, congifuration and WSGI variables are displayed, and in the configuration section we have this line: >>>>>> ucsc_display_sites: 'main,test,archaea,ucla' >>>>>> >>>>>> Did we miss anything? Where should we start searching for a possible error source? >>>>>> >>>>>> Thanks, >>>>>> L-A >>>>>> >>>>>> >>>>>> >>>>>> Le 23/11/2011 16:11, Greg Von Kuster a écrit : >>>>>>> Hello Nicolas, >>>>>>> >>>>>>> On Nov 22, 2011, at 11:04 AM, Nicolas Delhomme wrote: >>>>>>> >>>>>>>> Hi Greg, >>>>>>>> >>>>>>>> I've been scanning the mailing list, but wasn't lucky enough to find the answer I was looking for. >>>>>>>> >>>>>>>> Basically, we would be interested to have our own Galaxy Tool Shed in-house, to develop and test tools within our local Galaxy instance. What I'm thinking of, is to use the power of the tool shed to develop new algorithm, new tools, etc. that could be published afterwards. >>>>>>> This is great, but keep in mind that the intent of the tool shed (whether it is a local, proprietary tool shed or the public Galaxy tool shed) is to provide a vehicle for sharing tools (and tool-related objects like workflows, data types, etc) that are determined to be functional within a Galaxy instance. So the primary use of a tool shed should be to enable sharing. The tools themselves should be implemented within a development environment that includes a Galaxy instance, and when a tool is deemed functional, it can then be uploaded to the tool shed for sharing. >>>>>>> >>>>>>> You can, however, tweak the primary intent of a tool shed to meet your needs. In your case, it seems that you may be interested in using a local tool shed instance to share tools between developers during the development process. If this is the case, then your approach can be one where a developer creates a repository on the local tool shed multiple developers can clone it. The mercurial command line process for committing, pushing, pulling and updating can be used to share updates to the tool code by multiple developers throughout the process. >>>>>>> >>>>>>> If a single developer is implementing the tool however, it may make more sense to not use the tool shed as part of the development process - just upload the tool when it is functional. >>>>>>> >>>>>>> >>>>>>>> Because these would be sensitive material, we would not want to put them right away on the public test Tool Shed. Having a local Tool Shed instance would still be very helpful in releasing these tools to the community afterwards, as they would have been integrated and developed within that framework from the start. >>>>>>> This is a good approach. >>>>>>> >>>>>>>> Any pointers on how to achieve this are welcome as I'm not so familiar with the Tool Shed yet, e.g. would making a local clone of the tool shed repository be enough? >>>>>>> Make sure to read the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. I make sure to keep this up-to-date with the latest features of the tool shed. You'll ffind, however, that there are some tool shed admin user features that have not yet been documented. If you have any question, let me know. >>>>>>> >>>>>>> The tool shed is included in the Galaxy distribution, so no additional cloning is necessary - it is just a different webpp from Galaxy itself. It uses a different database from Galaxy, which you configure in the file community_wsgi.ini (the equivalent of universe_wsgi.ini for Galxy). After you have the configuration settings as you want them, start up your local tool shed by: >>>>>>> >>>>>>> %sh run_community.sh >>>>>>> >>>>>>> Feel free to ask questions! >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Nico >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> Nicolas Delhomme >>>>>>>> >>>>>>>> Genome Biology Computational Support >>>>>>>> >>>>>>>> European Molecular Biology Laboratory >>>>>>>> >>>>>>>> Tel: +49 6221 387 8310 >>>>>>>> Email: nicolas.delhomme@embl.de >>>>>>>> Meyerhofstrasse 1 - Postfach 10.2209 >>>>>>>> 69102 Heidelberg, Germany >>>>>>>> --------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ___________________________________________________________ >>>>>>>> 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/ >>>>>>> Greg Von Kuster >>>>>>> Galaxy Development Team >>>>>>> greg@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/ >>>>>> >>>>> Greg Von Kuster >>>>> Galaxy Development Team >>>>> greg@bx.psu.edu >>>>> >>>>> >>>>> >>>> >>>> <community_wsgi.ini><run_community.sh>___________________________________________________________ >>>> 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/ >>> >>> Greg Von Kuster >>> Galaxy Development Team >>> greg@bx.psu.edu >>> >>> >>> >> > > Greg Von Kuster > Galaxy Development Team > greg@bx.psu.edu > > >
Greg Von Kuster Galaxy Development Team greg@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:
Greg Von Kuster Galaxy Development Team greg@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:
Greg Von Kuster Galaxy Development Team greg@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:
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
participants (3)
-
Greg Von Kuster -
Louise-Amélie Schmitt -
Nicolas Delhomme