I'm actually still a bit confused as to what the expected workflow is.
Should I be able to clone the tool shed repo to my local development
workstation (TOOL_DEV_LOCAL_DIR), commit a change, and then push that
change back to the Tool Shed?
I've added some comments inline to clarify.
Greg Von Kuster wrote:
Not quite. I would typically create the repository using the Tool Shed
web interface. Then, on my local workstation, I would create the
TOOL_DEV_LOCAL_DIR by using the 'hg clone http://toolshedurl/repo' command.
I need to figure out precisely what steps you are taking to produce
this behavior, as I have not been able to do so. Please see my inline
comments, and let me know more information about each step you are
taking to produce this behavior.
On Sep 25, 2012, at 10:24 AM, Lance Parsons wrote:
I'm sorry I wasn't more clear. I do believe that those links explain
the behavior I am seeing. However, let me try to describe it a
different way. It seems that there will, at most, be one installable
revision of a given version of a tool. Here I use revision to denote
a mercurial revision and version to denote the version described in
the tool's config xml. However, while it seems this is the desired
behavior, it seems to lead to an undesirable situation in some
circumstances. Consider this scenario:
1) Upload version 0.1 of MYTOOL at revision 0:XXXXXXXX to the tool shed.
I assume you are uploading the initial tarball or separate files from
a certain local directory. Let's call it TOOL_DEV_LOCAL_DIR.
Yes, I use the Galaxy Admin interface to install the tool from a tool
shed to my Galaxy instance.
2) Install version 0.1 of MYTOOL at revision 0:XXXXXXX to my local
This now creates a new mercurial repository at a specified location on
your Galaxy server, let's call it REPO_INSTALL_DIR.
3) Modify MYTOOL, leaving the version at 0.1,
You are doing the above step in TOOL_DEV_LOCAL_DIR, correct?
Yes, I modify the files in TOOL_DEV_LOCAL_DIR, leaving the version the same.
I don't think so. I would typically commit the changes by issuing an
'hg commit' while in my TOOL_DEV_LOCAL_DIR and then push them to the
tool shed using the 'hg push' command.
but changing the revision to 1:YYYYYYYY.
The tool shed is creating the new change set hash for you when you
push the changes from TOOL_DEV_LOCAL_DIR to the repository in the tool
Right, I think we're on the same page here, though this should probably
be spelled out somewhere in a "Best Practices" type document for tool
development (which could also help to clarify the steps to setup a sane
development environment, test tools, and push them to the public tool
shed. I've not even quite gotten a solid workflow for myself, so
publishing one might be useful.
These updates would be for things that don't change the input or
output of a tool (such as updates to documentation, the addition of
tool dependencies, etc.)
OK, this make sense.
4) Attempt to update MYTOOL from my local Galaxy instance.
You are using the Galaxy UI to "Get updates" to your cloned
repository, which is located in REPO_INSTALL_DIR, correct?
Yes, then I use the Galaxy web admin interface to "Get updates".
I don't add changesets to the REPO_INSTALL_DIR, but instead make changes
in TOOL_DEV_LOCAL_DIR, commit them using mercurial, and then push them
to the tool shed using hg push.
This now results in an exception: "RepoLookupError: unknown revision
If answers to all of my above questions are "Yes", then this is where
I cannot reproduce the behavior you are seeing. If you are actually
adding changsets to your cloned repository located
in REPO_INSTALL_DIR, then pushing them to the repository in the tool
shed, then attempting to get updates from the tool shed to your cloned
repository in REPO_INSTALL_DIR, then this process may be causing the
exception you are seeing. You should not be adding changesets to the
cloned repository, but to your local development environment
Deactivating and/or uninstalling MYTOOL works, but any attempt to
reinstall the latest version results in an error stating that an
older revision of the tool was installed. I now have to way to
(easily) update my local Galaxy instance to this updated revision of
My only workaround to this was to increment the version of MYTOOL and
push another revision. This allowed me to install the new version and
deactivate the old version in my local Galaxy instance.
As for the mercurial issue, I'm running OS X, using the Homebrew
version of Mercurial:
Mercurial Distributed SCM (version 2.3.1)
(see http://mercurial.selenic.com for more information)
Copyright (C) 2005-2012 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
I'm running version 2.2.3, so I'll upgrade to version 2.3.1 to see if
the newer version breaks my environment.
Lance Parsons - Scientific Programmer
134 Carl C. Icahn Laboratory
Lewis-Sigler Institute for Integrative Genomics
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: