create_db and manage_db should now work with install as well.
Migrations are symbolic links into lib/galaxy/model/migrate/versions of migrations affecting these tables. All future migrations to these tables should created in one place like this and linked in the other.
Now app.model and app.install_model may be two distinct objects not just two references to the same object. Add ModelMapping class for galaxy.model.tool_shed_install.
If install_database_connection is set in Galaxy configuration, a separate database will be targetted for the persistence of the tool shed repository information. Additional database options may likewise be specified in this case: install_database_engine_option_pool_size, etc....
All references to galaxy.model.tool_shed_install models should go through this instance. Right now it is a reference to the same ModelMapping instance, but the goal is to allow them to be two different mappings.
Specifically, refactor all tool shed installation related models and mapping information in Galaxy's models into new module galaxy.model.tool_shed_install.
This is work toward being able to store tool shed installation data into a second database. There is still a lot TODO, all access to these models are still through galaxy.model and the existing ModelMapping object, these references need to be refactored.
More information on the end goal here: http://dev.list.galaxyproject.org/Galaxy-less-Tool-Installing-tp4660655.html.
Shared across Tool Shed and Galaxy to reduce code duplication. Previously this was just a bunch, making it a real class allows placing some shared logic in there.
This refactoring also eliminates some global variables galaxy.model.mapping.Session, galaxy.model.mapping.context, and same for tool shed. This may break things, but these are things that should probably be fixed anyway.
In particular small changes to db_shell.py and a unit test that depended on these global variables have been updated. The functional test frameworks likewise needed to be updated to not depend on these - these changes were more substantial.
To fix these functional tests, I essentially replace old references to global variables in Galaxy with references to global variables just defined in the test framework in test/functional/database_contexts.py (a slight improvement).
Namely create_db.py,db_shell.py, and manage_db.py.
Move duplicated code into lib/galaxy/model/orm/scripts.py - add unit tests. PEP-8 clean up of all 4 files. Add incoherent incoherent comment at top of manage_db.py.
As a result of the code de-duplication create_db.py should be usable with the tool shed now.
Will be refactoring lib/galaxy/model/orm/scripts.py to work with new tool shed install database - it will be good to have a place to test these and allow manage_db.py and clean_db.py to work immediately.
Basically adds __init__.py files to each subdirectory so nose detects these as Python module directories. Also modify dynamic loading of modules in Carl's test cases so the test case can be run with any cwd - including the Galaxy root directory as run_unit_tests.sh will use.
This should roughly double the number of unit tests buildbot runs.
Looks to have been replaced by method with same name in install_and_test_tool_shed_repositories/functional_tests.py and would throw a NameError on repository_id if ever used.
This changeset implements an object store implementation that delegates to a concrete remote object store instance via an LWR server. Can utilize existing LWR security mechanisms and multiple transport options.
Updates the Galaxy LWR client through LWR changeset 2333f57.
This changeset contains no tests for this new implementation, but the LWR contains the same code along with an integration test that spins up a temp LWR to test against - this test case demonstrating the lwr object store client and server can be found here : https://bitbucket.org/jmchilton/lwr/src/default/test/lwr_objectstore_test.py.
Be explicit about what in galaxy.util is being used, don't fail if galaxy.eggs is unavailable - assume the actual dependencies will be there (boto and rods) if not fail just a little later. If nothing else, this should fix some failing buildbot tests (nosetests records a failure if it cannot import a file and it cannot import the s3 or irods object store files because of these imports).
This eliminates explicit dependency between galaxy.objectstore and galaxy.job - with the ultimate goal of being able to utilize all object store functionality except dataset creation from a remote LWR instance with minimal dependencies.
John Chilton