Hi Lance,

On Sep 27, 2012, at 4:37 PM, Lance Parsons wrote:

> 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?

Assuming that you eliminate everything in your TOOL_DEV_LOCAL_DIR (you have a 
clean directory, eliminating any .hg directories that may exist), pull a fresh 
clone from the tool shed, make changes to the clone you've just pull into 
TOOL_DEV_LOCAL_DIR, push the changes to the tool shed, this should be fine.  

A better approach would probably be to simply keep your TOOL_DEV_LOCAL_DIR as 
the "master repository", never pulling to it from the tool shed (because no one 
except you is able to change the repository in the tool shed) and just pushing 
changes from TOOL_DEV_LOCAL_DIR to the tool shed repository.

So, the path is something like:

TOOL_DEV_LOCAL_DIR  pushes new changes to your tool shed repository, and others 
in the Galaxy community clone from your tool shed repository, including updates 
you committed over time

Greg Von Kuster

> I've added some comments inline to clarify.
> Greg Von Kuster wrote:
>> Hi Lance,
>> 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.
> 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.
>>> 2) Install version 0.1 of MYTOOL at revision 0:XXXXXXX to my local Galaxy 
>>> instance.
>> This now creates a new mercurial repository at a specified location on your 
>> Galaxy server, let's call it  REPO_INSTALL_DIR.
> Yes, I use the Galaxy Admin interface to install the tool from a tool shed to 
> my Galaxy instance.
>>> 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.
>>> 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 shed, correct?
> 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.
>>> 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.
> 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.
>>> 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".
>>> This now results in an exception: " RepoLookupError: unknown revision '1' ".
>> 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 in TOOL_DEV_LOCAL_DIR.
> 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.
>>> 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 the tool.
>>> 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:
>>> hg --version
>>> 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
>> 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
> Princeton University

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:


Reply via email to