Hi Peter, see below...
On Feb 19, 2013, at 5:10 AM, Peter Cock wrote:
On Sat, Feb 16, 2013 at 9:41 PM, Greg Von Kuster email@example.com wrote:
Thanks for your thoughts on this. I've created the following Trello card for this enhancement.
The priority for the tool shed in the area of tool dependencies like this has been the implementation of features that enable sharing a single dependency across multiple tools in separate repositories, so your scenario is not yet supported.
This enhancement would actually be as much (or perhaps more) on the Galaxy end than the tool shed, I think, so there may be more resources available to get to it sooner than I can right now. Of course, someone wil get to it as soon as possible.
Thanks again for all of your feedback and insight on this.
Greg Von Kuster
I've read http://wiki.galaxyproject.org/InstallingRepositoriesToGalaxy which is targeted at Galaxy administrators rather than tools authors. It explains how a revision specific folder is assigned to each installed tool, but what (if anything) of the Tool's folder structure is preserved?
The installation process uses the mercurial API, so the process to install a specific repository changeset_revision ultimately includes the following 2 hg commands.
hg clone <repository_clone_url> hg update -r changeset_revision
This results in the structure of the installed repository being exactly the same of the specific revision from which the repository was cloned.
e.g. One of the paths given is:
The prefix is the revision specific path for that tool for that Tool Shed,
Within that, it seems to preserve the emboss_datatypes folders. i.e. goto http://toolshed.g2.bx.psu.edu/view/devteam/emboss_datatypes and click browse repository tip files from the top left actions menu, it has just one file: emboss_datatypes/datatypes_conf.xml
Yes, the complete directory hierarchy and content of the original repository revision is preserved when it installed into Galaxy.
Based on a sample of one, it seems the installation process just unpacks the tool shed files (well, probably using hg rather than unpacking a tar-ball), and preserves their relative path structure. If so, I can just use relative paths to find a data file from the tool executable's own location on disk. (This is what I was hoping would be the case - I'm looking for explicit confirmation).
This is correct, hg clone provides this behavior.
i.e. For the example use case, if motif.py and motif.dat are in the same folder in the Tool Shed upload, they will be in the same folder as each other once installed. That way motif.py can easily locate the data file motif.dat by looking in the same folder as it itself is located. This is actually very simple (provided I can assume the local folder structure is maintained).
Yes, this is correct.
(I think I was originally on the wrong track by assuming I should be using the tool-data folder, which is complicated by not knowing where that will existing on disk).
I think your request is still valid though and we will add this enhancement for the Galaxy tool component to handle $REPOSITORY_INSTALL_DIR in tool configs. In the meantime, it looks like you can work around this missing feature. Please let me know if you bump into issues.