On Oct 24, 2013, at 4:06 PM, "Guest, Simon" <simon.gu...@agresearch.co.nz>
> Hi Greg,
> Thanks for the explanation, and the link to that helpful Wiki page.
> And also that code update 11114:71c35dbde130 which will help our tool
> test/development cycle.
> I have a remaining question, though, about the recommended working
> practices for developing a toolshed tool. I didn't find this
> described on the Wiki. There is obviously a cycle of development to
> go through, making updates, installing to a test galaxy instance, etc.
> It seems to us that the only sensible way to handle this is within a
> local test toolshed, essentially using the repo in the test toolshed
> as a development repo (despite the warnings not use the toolshed as a
> source code repo on the Wiki!).
This is certainly a good approach, although using a local tool shed as a
component of the devlopment process when developing tools is probably useful
only when your repository includes repository dependency definitions or tool
dependency definitions. In these cases, the tool shed encironment becomes
useful for working out the details of the dependencies and making sure that
everything ( all repository and tool dependencies ) installs correctly into
your local Galaxy instance.
In cases where you are developing simpler tools ( e.g., Text Manipulation tools
like filter and sort ) that are completely self contained ( they have no
dependencies ), using a local tool shed during the development process is
probably not necessary.
> During such an iterative process, we
> don't want to keep bumping the tool version.
It may ot be necessary to do so - the only time you should be bumping the tool
version ( which is a manual process of changing the version string in the tool
config ) is when the tool behavior changes such that the same input dataset
produces defferent resulting output datasets(s).
> Therefore it seems
> necessary to reset the repository meta data after every push, in order
> to install the just-updated-for-testing tool.
If you are using mercurial ersion 2.2.3 or later in your shell environment,
then pushing to your local tool shed from the command line should be resetting
metadata back to the last installable changeset revsion. If you are not seeing
this behavior, make sure you are using that version or later - see
> Once the tool is
> working, the files can be uploaded into a clean repo on a production
> toolshed, so we don't keep all the intermediate development versions.
Yes, this is definitely the correct approach if you do find that using a local
tool shed during the development process is beneficial.
> Or is there a better way to do this?
I think you have things pretty well figured out. Don't hesitate to continue to
ask questions as they arise.
> 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:
> To search Galaxy mailing lists use the unified search at:
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:
To search Galaxy mailing lists use the unified search at: