Hi Peter,

On May 13, 2013, at 12:13 PM, Peter Cock wrote:

> 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.


No, nothing EARLIER is installed, only revisions that came LATER (than the 
declared dependency revision) up to, but not including the next revision in the 
change log (AFTER the declared dependency revision) that has metadata 
associated with it.  If you look at the change log page for a repository in the 
tool shed, you'll see all of the revisions that have metadata associated with 
them.


> 
> (Here I'd have called X a "maximum" revision, but this is seemingly
> open to two opposite view points - thus our confusion).
> 
> 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.


This is actually the case, so I'm not sure what I stated in the example above 
that caused the confusion.


> 
> I guess this means an option to explicitly ask for the latest revision
> would be regarded as counter to the Galaxy reproducibility goals?

Not necessarily, but there is a Trello card here:

https://trello.com/card/toolshed-add-the-ability-to-deprecate-a-repository-revision/506338ce32ae458f6d15e4b3/768

based on a request at the last IUC teleconference that could easily impact 
reproducibility.  This request will take careful consideration in how it is 
implemented so that we can ensure reproducibility.


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


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

Reply via email to