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