On 26 February 2013 21:02, Chris Muller <ma.chris.m at gmail.com> wrote:
> On Tue, Feb 26, 2013 at 2:38 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 26 February 2013 19:13, Chris Muller <ma.chris.m at gmail.com> wrote:
>>> What I did in my MaInstaller was to have a #merge: function which
>>> would normally be used all the time (instead of #install:).  So
>>> whichever one was more up-to-date would be loaded or, even if they
>>> were branches of each other it would still work too as long as there
>>> were no method-level conflicts.  (If there are method-level conflicts
>>> then the interactive Merge dialog is presented where the user can make
>>> a choice and proceed with the rest of the install by clicking Merge).
>>>
>>> If something isn't installed at yet, #merge: behaves exactly like #install:.
>>
>> OK, but that's not what I'm getting at. It's not actually a problem
>> yet because this thing's not finished, but my point is that we'd have
>> two things that lazily pulled in WebClient... and if SM simply had to
>> use version N or later, and InstallerGitHub pulled in version N-1
>> because you ran it before you opened the catalog, Bad Things might
>> well happen. Especially so since "is WebClient installed?" is answered
>> by Smalltalk at: #WebClient (really, this should be self class
>> environment at: #WebClient). SM goes "oh cool, it's already loaded, so
>> I'll just invoke this new behaviour OH NO MNU"
>
> Hmm, so it seems to me the unconditional merge idea still solves all
> cases including that one doesn't it?  If SM was second, it would merge
> version N prior to its work.  If InstallerGitHub was second, its merge
> of N-1 would have no effect since it was already in the ancestry..
>
> In any case, as you said, this hardly seems like an issue because, if
> it were, the energy to rectify it wouldn't be to make them operate on
> different verisions but on the same, (most-recent) version.

The unconditional merge only works if you always install WebClient
prior to some action. That will involve at the least a round trip to
the package-cache, which is a bit wasteful.

And yes, the solution is to make sure that both (all) things used the
same (most recent) version - that's kind've my point :) But maybe we
should stick to the "3 strikes and then refactor" rule and not worry
about it for now.

frank