Hello Simon,
On Oct 24, 2013, at 4:06 PM, "Guest, Simon" <simon.gu...@agresearch.co.nz> wrote: > > 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 http://wiki.galaxyproject.org/ToolShedRepositoryFeatures#Pushing_changes_to_a_repository_using_hg_from_the_command_line > 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. > > cheers, > Simon > ___________________________________________________________ > 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: > http://lists.bx.psu.edu/ > > To search Galaxy mailing lists use the unified search at: > http://galaxyproject.org/search/mailinglists/ ___________________________________________________________ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
