Hello Will,

On Jun 17, 2014, at 6:06 PM, Will Holtz <who...@lygos.com> wrote:

> It looks like Dave fixed this issue in 4c58aa19a3d7. Thank you!
> However I am still having import issues. I am now getting the message:
> "Archive of repository package_bowtie_0_12_7 owned by devteam
> Import failed: repository owner devteam does not have an account in this Tool 
> Shed."
> This is on a local toolshed running 9b78595ec11 where I am performing the 
> input from an admin account. I'm guessing the issue is that I have 
> 'use_remote_user=True' for LDAP authentication and that means that a devteam 
> account cannot be automatically created to allow this capsule to be added 
> without modification.

Sorry you're still running into problems.  No regular development or testing is 
done using the use_remote_user setting due to resource limitations.

> Perhaps on import of a capsule (by an administrator) they could be given the 
> option of preserving the existing owners or re-assigning ownership to an 
> existing user (defaulting to self)?

This would be non-trivial, and probably would introduce fragility into the 
process.  However, I believe there is a solution (see my next comment) although 
I haven't tested it with the use_remote_user setting.
> Of course, what I really want is inter-toolshed dependancies. Maybe I'm 
> missing something, but I'm finding it quite painful just to get a tool 
> development environment setup that makes use of any existing repositories.

There was some work done in this area in the June 2, 2014 release.  Here is 
some information for more easily setting up a local development Tool Shed that 
use new features introduced in the release.  Hopefully this will help.

Greg Von Kuster
Bootstrapping a New Development Tool Shed

The June 2, 2014 release introduces the ability to easily bootstrap a new 
development Tool Shed to prepare it for importing a repository capsule whose 
contained repositories can be used as the foundation for developing new Galaxy 
tools and other utilities.  This development Tool Shed can be treated as a 
component in a multi-step process that simplifies and streamlines Galaxy tool 
development and validation in the local Tool Shed and moving the validated 
repositories into the test or main public Galaxy Tool Sheds.  Tool Shed 
framework enhancements included in the June 2, 2014 release support this 
overall process, which will be explained fully in a future article.  Here we’ll 
restrict our discussion to highlights of the enhancements.

Several files are included in a new directory named 
~/lib/tool_shed/scripts/api/bootstrap_from_toolshed.  The file named 
user_info.xml.sample should be copied to a file  with the same name, but 
eliminating the .sample extension (i.e., user_info.xml).  The information in 
this file is used to automatically create a new “admin” user account in your 
local development Tool Shed.  This should be the account you use in the test 
and main public Galaxy Tool Sheds if you plan to export your work from your 
development Tool Shed and import it into one or both of the public Tool Sheds.

If you plan to use this new bootstrapping process, make sure your local 
development Tool Shed environment is pristine:

The hgweb.config file must be empty or missing (it will automatically get 
created if it doesn’t exist) and the configured location for repositories must 
be an empty directory.
The configured database must be new and not yet migrated.
Make sure the ~/lib/tool_shed/scripts/api/bootstrap_from_toolshed/user_info.xml 
file contains the desired account information.
The ~/run_tool_shed.sh script, used for starting up a Tool Shed, has been 
enhanced to enable this bootstrapping process by using a new 
-bootstrap_from_tool_shed flag.  Here’s an example.

%sh run_tool_shed.sh -bootstrap_from_tool_shed http://toolshed.g2.bx.psu.edu
The above example will initialize a local development Tool Shed (here we’ll 
assume its URL is http://localhost:9009) by bootstrapping from the main public 
Galaxy Tool Shed.  The bootstrapping process will perform the following actions 
in the order listed.

Ensure the Tool Shed environment is pristine (e.g., empty hgweb.config file and 
new database that has not been migrated).
Copy all .sample files configured in run_tool_shed.sh.
Run the database migration process.
Execute the script 
~/tool_shed_wsgi.ini to create a new user and an associated API key using the 
information defined in 
Automatically modify the ~/tool_shed_wsgi.ini file to configure the above user 
as an admin_user for the Tool Shed.
Start the Tool Shed web server.
Execute the script ~/lib/tool_shed/scripts/api/create_users.py -a <api_key> -f 
http://toolshed.g2.bx.psu.edu -t http://localhost:9009.
Execute the script ~/lib/tool_shed/scripts/api/create_categories.py -a 
<api_key> -f http://toolshed.g2.bx.psu./edu -t http://localhost:9009.
Executing the run_tool_shed.sh script using this new flag as shown in the 
example above will create a new local development Tool Shed with an admin user 
automatically created and configured and the Tool Shed populated with all of 
the users and categories from the main public Galaxy Tool Shed.  This 
simplifies the process of exporting a repository capsule from the main public 
Tool Shed and importing it into the local development Tool Shed for further 

> thank you for your help,
> -Will
> On Wed, Jun 11, 2014 at 12:40 PM, Will Holtz <who...@lygos.com> wrote:
> I am now able to export capsules from the main/test toolsheds -- thanks Dave! 
> When attempting to import these capsules into my local toolshed 
> (latest_2014.06.02 for changeset fb68af9a775a) I receive the following error:
> URL: https://galaxy.lygos.com:99/repository/import_capsule
> File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/middleware/error.py', 
> line 149 in __call__
>   app_iter = self.application(environ, sr_checker)
> File 
> '/home/galaxy/galaxy-dist/eggs/Paste-',
>  line 106 in __call__
>   environ, self.app)
> File 
> '/home/galaxy/galaxy-dist/eggs/Paste-', 
> line 543 in intercept_output
>   app_iter = application(environ, replacement_start_response)
> File 
> '/home/galaxy/galaxy-dist/eggs/Paste-', 
> line 84 in __call__
>   return self.application(environ, start_response)
> File 
> '/home/galaxy/galaxy-dist/lib/galaxy/webapps/tool_shed/framework/middleware/remoteuser.py',
>  line 74 in __call__
>   return self.app( environ, start_response )
> File 
> '/home/galaxy/galaxy-dist/eggs/Paste-',
>  line 633 in __call__
>   return self.application(environ, start_response)
> File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 132 in 
> __call__
>   return self.handle_request( environ, start_response )
> File '/home/galaxy/galaxy-dist/lib/galaxy/web/framework/base.py', line 190 in 
> handle_request
>   body = method( trans, **kwargs )
> File 
> '/home/galaxy/galaxy-dist/lib/galaxy/webapps/tool_shed/controllers/repository.py',
>  line 1992 in import_capsule
>   import_util.check_status_and_reset_downloadable( trans, import_results_tups 
> )
> File '/home/galaxy/galaxy-dist/lib/tool_shed/util/import_util.py', line 34 in 
> check_status_and_reset_downloadable
>   tip_changeset_revision = repository.tip( trans.app )
> AttributeError: 'NoneType' object has no attribute 'tip'
> I have seen the same behavior for capsules based on the following 
> repositories from the test toolshed: package_biopython_1_62, 
> package_vienna_rna_2_1, and package_bowtie_0_12_7. I am logged in as an admin 
> user for the import process.
> thanks,
> -Will
> ___________________________________________________________
> 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/
> To search Galaxy mailing lists use the unified search at:
>  http://galaxyproject.org/search/mailinglists/

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:

To search Galaxy mailing lists use the unified search at:

Reply via email to