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

Reply via email to