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