Hi Greg,

I used the toolshed bootstrapping script and was able to get capsules from
testtoolshed to import. Here are a couple of notes that you may find

1) In a few places you reference the directory
~/lib/tool_shed/scripts/api/bootstrap_from_toolshed/ and these should be
changed to ~/lib/tool_shed/scripts/bootstrap_from_toolshed/
2) I was worried that 'use_remote_user=True' was going to negatively impact
the bootstrap process, as accounts are being created that don't exist in
LDAP. However, there didn't appear to be any such negative interaction. In
user_info.xml I used my email address that maps to my LDAP login (
who...@lygos.com), a long gibberish password, and wholtz for my username.

Thank you for your help Greg.


On Tue, Jun 17, 2014 at 7:51 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:

> 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 
> *~/lib/tool_shed/scripts/bootstrap_tool_shed/create_user_with_api_key.py
>    ~/tool_shed_wsgi.ini* to create a new user and an associated API key
>    using the information defined in
>    *~/lib/tool_shed/scripts/bootstrap_tool_shed/user_info.xml.*
>    - Automatically modify the ~/t*ool_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
>    <http://toolshed.g2.bx.psu.edu> -t http://localhost:9009
>    <http://localhost:9009>.*
>    - Execute the script *~/lib/tool_shed/scripts/api/create_categories.py
>    -a <api_key> -f http://toolshed.g2.bx.psu./edu
>    <http://toolshed.g2.bx.psu./edu> -t http://localhost:9009
>    <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 development.
> 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