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 Von Kuster
Galaxy Development Team
Greg Von Kuster
Galaxy Development Team
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
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