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