Am Montag, den 13.05.2013, 17:13 +0100 schrieb Peter Cock: > On Mon, May 13, 2013 at 4:03 PM, Greg Von Kuster <g...@bx.psu.edu> wrote: > > Hello Björn, > > > > On May 12, 2013, at 12:36 PM, Björn Grüning wrote: > > > >> Hi Greg, > >> > >>> The current revision setting is treated as a minimum, so any available > >>> updates are retrieved automatically at the time of installation. > >> > >> if I get that right, we should always have the latest revision > >> installed, regardless of the specified requirement revision. Is that > >> correct? > > > > No, this is not correct. By "minimum", we mean that the revision setting > > is treated as a minimum within the set of changeset revisions up to, but > > not including, the next installable changeset revision in the change log. > > > > For example, assume a change log like this: > > > > changset revision Installable revision > > > > 0: sjekvub yes > > 1: jjtofvp > > 2: htocegy > > 3: jswofpt yes > > 4: jaqvkrc > > > > In the above example, sjekvub is considered the "minimum revision for revs > > 0, 1, 2, and jswofpt is considered the minimum revision for revs 3, 4. If > > a dependency definition defined revision sjekvub, then what will actually > > be installed is "2: htocegy". > > > > This approach guarantees reproducibility. For example, assume revision 0: > > sjekvub contains version 1 of tool A and revision 3: jswofpt contains > > version 2 of tool A. If you install 0: sjekvub, then you cannot upgrade > > beyond 2: htocegy for that specific repository installation. To get > > version 2 of tool A you have to install revision 3: jswofpt of the > > repository as a separate installation. > > > > This ensures that both versions of the same tool are always available to > > you for reproducibility. > > > > This information is document in the following section of the tool shed wiki: > > > > http://wiki.galaxyproject.org/RepositoryRevisions > > > >> > >> I do not think that is working atm. It seems its using an exact match. > > > > If you are seeing behavior that contradicts the above information or the > > information in the tool shed wiki, please let me know some specifics. > > > > > > Thanks!
> Woosh - that largely went over my head. It sounds rather complicated. > Did I get the gist right: > > To paraphrase, if I declare a dependency on revision X, then what will > be installed could be X or an EARLIER revision - stepping back until > an installable revision is found. > > (Here I'd have called X a "maximum" revision, but this is seemingly > open to two opposite view points - thus our confusion). As far as I understood, every revision that did not change any metadata will be marked as 'preferred installable', the revision before looses these tag. Any change to metadata will create an additional tag. So we end up with two 'preferred installable' tags. If I now specify a version that has no tag, toolshed will climb the revision history until it will find a 'preferred installation' tag. That has the same metadata as my specified version. In the end I get either my specified version or a later version, but not the necessarily the latest. > That is very different to what I (and Bjorn?) had understood you to mean > by "minimum", namely if we declare a dependency on revision X, then > we'll get either X or a LATER revision. Yes, that also confused me ... > I guess this means an option to explicitly ask for the latest revision > would be regarded as counter to the Galaxy reproducibility goals? The point of that short cut is that my git changelog will get spammed with revision changes and during development I will only need the latest version of a dependency, or? So leaving the revision field empty means the toolshed should include the latest current revision of my dependency automatically. For the reproducibility nothing will change I think. In the toolshed its filled with a specific revision. Only on my development box and git account its empty. > Thanks, > > Peter ___________________________________________________________ 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/
