Re: [galaxy-dev] Local installation of the tool shed

[Greg Von Kuster]

Hello Louise-Amelie,


On Dec 1, 2011, at 4:08 AM, Louise-Amélie Schmitt wrote:

> Yes this fixes the problem, it should work fine now :)
> 
> Thanks a lot!
> 
> Hehe, next issues:
> 
> 1) When I have my repo created and I click on the "Upload files to 
> repository", I get a Not found error in the browser:
> Not Found
> The requested URL /toolshed/upload/upload was not found on this server.

This is probably due to your apache rewrite rule: 

RewriteRule ^/toolshed/upload/(.*) 
/home/galaxy/galaxy-dev/static/automated_upload/$1 [L]

Is this something proprietary you have set up on your local galaxy instance?  
Try removing it from your rewrite rules for your local tool shed.


> 
> 2) When we try to access our local toolshed from our Galaxy instance, it 
> appears in the "Accessible tool sheds" list along with your two public repos, 
> but when we click on it, the "Valid repositories" list is empty. Is this a 
> bug or does a repo have to actually contain files so it can appear in this 
> list?

The list of valid repositories will only include repositories that have content 
that is valid for a Galaxy instance.  These repositories are defined as either 
"valid" or in some cases "downloadable" (I'm working to replace the latter with 
the former).  See the following sections of the tool shed wiki for details:

http://wiki.g2.bx.psu.edu/Tool%20Shed#Repository_revisions:_downloadable_tool_versions
http://wiki.g2.bx.psu.edu/Tool%20Shed#Automatic_installation_of_Galaxy_tool_shed_repository_tools_into_a_local_Galaxy_instance

> 
> 3) Where should the hgweb.config be?

This file should be left in the Galaxy root install directory.


> Actually, we have absolute paths since in the community_wsgi.ini we set the 
> file_path option to an absolute path.

I advise against this - I'm fairly certain it will pose problems at some point. 
 Tool shed paths should be relative.  Here are some example entries in only of 
my local tool sheds:

[paths]

repos/test/filter = database/community_files/000/repo_1
repos/test/workflow_with_tools = database/community_files/000/repo_2
repos/test/heteroplasmy_workflow = database/community_files/000/repo_3



> 
> Thanks for your patience!
> L-A
> 

Greg Von Kuster
Galaxy Development Team
g...@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/

Re: [galaxy-dev] Local installation of the tool shed

[Louise-Amélie Schmitt]

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
g...@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/

Re: [galaxy-dev] Local installation of the tool shed

[Greg Von Kuster]

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
g...@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/

Re: [galaxy-dev] Local installation of the tool shed

[Greg Von Kuster]

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 /templates/webapps/community 
> /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 -: '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
> 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 

Re: [galaxy-dev] Local installation of the tool shed

[Louise-Amélie Schmitt]

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 /templates/webapps/community 
/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 -: '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
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 

Re: [galaxy-dev] Local installation of the tool shed

[Greg Von Kuster]

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 -: '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
>>> 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 t

Re: [galaxy-dev] Local installation of the tool shed

[Louise-Amélie Schmitt]

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 -: '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
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 T

Re: [galaxy-dev] Local installation of the tool shed

[Greg Von Kuster]

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 - : '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 
> 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 To

Re: [galaxy-dev] Local installation of the tool shed

[Louise-Amélie Schmitt]

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 - : '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 
  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 use

Re: [galaxy-dev] Local installation of the tool shed

[Greg Von Kuster]

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.delho...@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
g...@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/

[galaxy-dev] Local installation of the tool shed

[Nicolas Delhomme]

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.delho...@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/