Jeremy,
 
I’m sure that would get both tools to show up, but it seems to me that would miss the goal of past/future reproducibility.
 
My goal is to have to two versions of the program available at the same time –
Cuffdiff_wrapper 0.0.5 (cuffdiff/links 1.3) the historical one that all the current histories/workflows reference, so those don’t break,
and
Cuffdiff_wrapper 0.0.6 (cuffdiff/links 2.1) the new version for use going forward, which has a distinct version so that those histories/workflows are reproducible
and the choice of which version to use is the users.
I want to avoid someone who wants to re-run last-month’s cuffdiff with slightly different parameters being forced (w/o their knowledge) to run a more recent version of cuffdiff – which would then give an apples to oranges comparison.
 
With 2 versions of the same ID installed, I expected to either see two listings in the tool pane AND/OR a version pulldown on the cuffdiff tool params pane.
 
Is the only way to get two versions of the same tool id installed via toolshed?

Yes.

Unfortunately, it's not possible to manually install multiple versions of the same tool; the development efforts of the Galaxy team are focused on multiple version installation via only the tool shed for now. However, we'd welcome a pull request that adds this functionality to Galaxy.

Given that you want to provide backward compatibility, it's probably best to keep the tool_id for the older Cuffdiff wrapper and change the new one; mercurial merges should handle this change gracefully as it's small.

Best,
J.


 
Sorry – I feel like I’ve mis-understood the tool version/id resolution architecture. Happy to talk on the phone if that would be a better use of your time.
 
Thanks,
Curtis
 
 
 
From: Jeremy Goecks [mailto:jeremy.goecks@emory.edu] 
Sent: Wednesday, September 25, 2013 8:43 AM
To: Curtis Hendrickson (Campus)
Cc: galaxy-dev@lists.bx.psu.edu; Shantanu Pavgi (Campus)
Subject: Re: [galaxy-dev] cuffdiff wrapper not synchronized with cuffdiff version
 
The problem is likely a collision on the tool_id; update the tool ID for one of the wrappers and that should solve the problem.
 
Best,
J.
 
On Sep 24, 2013, at 5:30 PM, Curtis Hendrickson (Campus) wrote:


Jeremy,
 
We didn’t have time to factor out to toolshed just now, so we took the following approach
1.       Take 1.3-compatible cuffdiff wrapper (0.0.5) and move it to cuffdiff_1.3_wrapper.py/xml – and add a dependency on cufflinks verson=1.3.0 (and set that up).
2.       Apply your patch, changing current cuffdiff wrapper to (0.0.6)
3.       Add a line in tool_conf.xml  so that both your modern cuffdiff v6 wrapper and our cuffdiff v5 wrappers are included.
 
When we restarted, and went to the GUI, there was only ONE cuffdiff tool listed, and when you clicked on it, it brought up the 0.0.5 version (the 2nd listed in tool_conf).
There was no version pull down to get the 0.0.6 version.,
 
Any idea what I’ve missed?
 
Regards,
Curtis
 
 
From: Jeremy Goecks [mailto:jeremy.goecks@emory.edu] 
Sent: Thursday, September 19, 2013 3:17 PM
To: Curtis Hendrickson (Campus)
Cc: galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] cuffdiff wrapper not synchronized with cuffdiff version
 
We can hack the old wrapper back in, using a hard-coded path to the old cuffdiff.
 
You could also use Managed Tool Dependencies for multiple versions of cuffdiff:
 



Shantanu suggests it might be a better world if we create a tool-shed repository for the cuffdiff 1.3-2.1 (wrapper 0.0.5) version, then install that.
Would that be a better path, or just add confusion?
 
This is on the right path. The right thing to do is migrate the Cuff* tool wrappers out of the galaxy-central/dist repositories; this is a bit more effort than simply creating the tool-shed repository for the wrappers.
 
There are two reasons I haven't done this:
 
(a) time;
(b) because the tools—and consequently the wrappers—are still in active development, there needs to be a place for managing development of the wrappers. Hence, the wrappers need a home on bitbucket or github, but we (the Galaxy team) haven't determined where these wrappers should live.
 
(a) is a much more significant barrier than (b), so if a pull request migrating Cuff* tools out of the distribution were made, I'm sure (b) could be worked out.
 
Best,
J.