I'm attempting to host a local instance of the Galaxy Tool Shed for development purposes. I've already gotten the Galaxy server up and running. I don't know where the Galaxy version number is located, but I have revision 78c9a97be4b6+ of galaxy-dist repository. I did manage to get the Tool Shed server working, but upon reading this blog post (see section "Hosting Your Own Tool Shed for Developing Galaxy Tools and Utilities"), I wanted to bootstrap from the main Galaxy Tool Shed (http://toolshed.g2.bx.psu.edu).
First of all, I'm trying to make use of PostgreSQL as the database backend. I have enabled the database_connection option in my tool_shed.ini configuration file using the appropriate postgresql:// connection string. However, the default SQLite database file in database/community.sqlite is still created, even with the database_file = database/community.sqlite line commented out in the tool_shed.ini config file. Is this normal? I can see a Galaxy-like schema in both the SQLite and PostgreSQL databases. However, I don't know which one is actually being used, as they're both empty. One thing is for sure: in order to re-run the bootstrapping command, the SQLite database file must be cleared. Otherwise, I get the following error:
Unable to bootstrap tool shed. The database configured for this Tool Shed is not new, so bootstrapping is not allowed. Create a new database that has not been migrated before attempting to bootstrap.
Second of all, while running the bootstrapping command (command and output), I run into a SQLAlchemy error claiming that the "repository" table doesn't exist. It's unclear which database it's referring to, but that table exists in both the SQLite and PostgreSQL databases. Therefore, I'm left wondering if it's referring to the public Tool Shed I'm bootstrapping from. Also, while the following steps say that they're "done", neither databases are populated with categories, nor with users. When I look into the tool_shed_bootstrap.log file, one thing I notice that that one of the GET HTTP requests fails with a 404 status ("GET /api/authenticate/baseauth/ HTTP/1.1" 404 - "-" "curl/7.35.0"), followed by many POST requests ("POST /api/users?key=a HTTP/1.1" 200 - "-" "Python-urllib/2.7"). Let me know if you could use any additional information to troubleshoot these issues.
