The public Galaxy test and main Tool Sheds are for sharing validated, functionally correct tools with the Galaxy community, not for developing them. As you've discovered, developing tools using the public Tool Sheds results in undesired behavior since you have restricted control over what can easily be eliminated from sharing. The primary reason for this is the Tool Shed's goal of reproducible analyses in galaxy. Any version of any Galaxy utility uploaded to the public Tool Shed will always be available for installation into Galaxy. This is the behavior you've seen when changing dependency versions, and similar behavior results when any Galaxy utility (tools, custom datatypes, Galaxy Data Managers, etc) version is changed.

Set up a local development Tool Shed - see the "Hosting Your Own Tool Shed for Developing Galaxy Tools and Utilities" section of: http://gregvonkuster.org/galaxy-tool-shed-introduction/
Export repositories containing validated tool dependencies from the main Galaxy Tool Shed into a capsule - see http://gregvonkuster.org/galaxy-tool-shed-leveraging-community-contributions-repository-capsules/
Import the capsule into your local Tool Shed.
Create an empty repository in your local Tool Shed to contain the new Galaxy tool.
Develop your tool in your local Galaxy environment, using the local Tool Shed as a source code repository if necessary.
When development is finished, make sure the finished tool is available in hyour local Tool Shed's repository and execute your local Tool Shed's Install and Test framework to validate the tool - see the "Using the Install and Test Framework With a Local Tool Shed" section of: http://gregvonkuster.org/galaxy-tool-shed-certifying-repositories-install-test-framework/
Export the repository containing the tool from your local Tool Shed.
Import the repository containing the tool into the test and main Galaxy Tool Sheds for additional validation and sharing.

Greg Von Kuster

On Jun 24, 2014, at 8:15 AM, Eric Kuyt <eric.kuijt@wur.nl> wrote:

Hi All,

I am playing around with putting a tool in testtoolshed. Now when changes to dependency versions are detected, the toolshed detects a new version and a dropdown is created.

but sometimes I do not want this behavior when the first version was erroneous for example. I tried hg strip on the repository and pushing it back to the testtoolshed but sadly it didn't result in a clean repository but a multi-headered mess.

Is there a way to cleanup the remote repository and start over. And what would be a cleaner way to develop tools on a toolshed still making use of repository dependencies?

Thanks,

Eric
___________________________________________________________
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/