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.
Also add PEP-8 cleanup and unit tests. This eliminates explicit dependency between galaxy.objectstore and galaxy.model - with the ultimate goal of being able to utilize all object store functionality except dataset creation from a remote LWR instance without a database connection.
Mostly small modifications related Python 3 compat. (no iteritems, diff. StringIO, exception syntax, urllib diffs,) and improved handling of unicode data.
Now symbolically linking to previously generated env.sh files instead of recreating them from scratch using install_and_build_package_via_fabric after inferring previous install parameters by parsing out existing env.sh file.
This has several advantages:
- Fixes problems where setup_* actions were not being used as complex dependency package properly (previous code assumed only set_environment and setup_virtualenv actions would work in this case). Problem reported by Bjoern Gruening.
- Handles deployer modified env.sh files and allows deployers to modify fewer env.sh.
- The way install_util was pulling values out of existing env.sh and recreating the files was creating a dependency on each future version of the install code with the specific implementations of past install procedures - new environment variables could not be added to setup_ruby_environment for instance if it was realized that they were needed.
Turns out the biggest difference between this and the previous implementation is related to handling of complex package dependencies where the dependent repository is not installed. Previously, the Galaxy install code would have attempted to create an env.sh file with the path modifications as they would look if it had been installed - i.e. with completely invalid paths. My translation of this behavior is to write an invalid symbolic link to the env.sh file that would be installed. I am not sure this has any practical consequences.
I would like to understand better why handling complex tool dependencies on dependent repositories that are not installed is done at all. Most package management systems, will prevent you from installing a package if dependent packages are not installed. This isn't to say what Galaxy is doing is wrong, it is just atypical and I would like to understand the use cases that lead to the decision better.
See 83a95ea606d9fcd15f7554b71804625e203eb1ed for full details (essentially GALAXY_TEST_DB_TEMPLATE can be sqlite file path or URL - will be copied over so original left in pristine state and auto upgraded as needed.
John Chilton