Thanks dale I will watch and read and sync with guys when I'm back to
civilisation :)


On Tue, Mar 6, 2018 at 6:35 PM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

>
>
> On 03/06/2018 06:21 AM, Guillermo Polito wrote:
>
> Hi Dale!
>
> On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
>>
>>
>> On 03/05/2018 09:07 AM, Guillermo Polito wrote:
>>
>>> On the other side, there is the fact that Metacello baselines are so far
>>> nice to describe release project dependencies, but they are not so nice to
>>> describe subprojects/development dependencies that may get edited along
>>> with the parent project. Kind of what we used to do with #bleedingEdge. I
>>> feel this is a complex problem, that not even SBT or maven that are there
>>> since years are capable of solving nicely... Tode and Iceberg metacello
>>> integration try to solve this problem by "ignoring the dependency and using
>>> the loaded repository" but this may not be successful either...
>>>
>>
>> I have not been following this thread in detail, but this comment leads
>> me to believe that the issue that you guys are running into has to do with
>> trying to ongoing distributed development across multiple projects and
>> multiple platform versions ...
>
>
> I don't know exactly the case of Calypso, but I don't think it is being
> maintained for other than latest Pharo 7.
>
> The Calypso case as I understand it is that it has a couple of dependencies
>
>  Calypso
>    | - commander
>    | - class annotations
>
> The three projects are hosted in different repositories, but Denis wants
> to work on "bleeding edge" of the three of them at the same time.
> Then when he loads calypso in a new image, if he just uses a baseline he
> will load specific versions of the dependencies and not the latest ones...
>
> I think this is the particular use case for locking, isn't it?
>
> Yes this is exactly the use case for locking.
>
>
>
>>
>> If so then I think that the moral equivalent of #bleedingEdge should be a
>> branch structure along the lines of:
>>
>>   master branch --- the project release that is known to work on all
>> supported platform versions.
>>   dev_pharo6      --- the current #bleedingEdge for Pharo6.0
>>   dev_pharo7      --- the current #bleedingEdge for Pharo7.0
>>
>> In an image where you want to use the dev_pharo7 for a project, you do a
>> Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE loading the
>> project ... if there are multiple projects that need to all coordinate
>> development then you follow the same convention and use a Metacello lock
>> for each of the projects ... Executing expressions to lock projects is
>> tedious to use and manage.
>>
>
> It is not that complicated I think ^^.
>
> I have found that "load specifications" are much easier to work with than
> "load expressions", similar to the way class definitions are superior to
> smalltalk code for creating classes, one can reason about a "load
> specification" for example it is possible to merge two load specifications
> to produce a single load specification whereas this kind of thing is not
> possible if you are given two arbitrary Smalltalk expressions to merge ...
>
>
>
>>
>> In tODE I started using project entries[1] that are downloaded to disk
>> and shared by multiple images that allow a developer to specify what
>> branch/tag/commit they are interested in using ... each image that is
>> started up in a "cluster" uses the project entry to do a Metacello lock on
>> the project "automagically"... if there is a series of projects where the
>> developer needs to use dev_pharo6 they can arrange to edit the project
>> entry to reflect the proper branches for the set of projects that need
>> special _development_ treatment ... these .ston files can be shared amongst
>> groups of developers ... of course once the local clones of these projects
>> are on the local disk, then it is up to the developer (or a set of scripts)
>> to periodically update to the latest development version of each of the
>> projects ...
>
>
> YES. This gets closer to what I want. What I don't like from locking is
> that I have to:
>   - know in advance all the projects (+ dependencies) I want to develop
> (specially if I'm not the main project developer)
>   - know where they are stored in the disk
>   - do an explicit locking on each of them
>
> Haha, and that is why I created the project entries ("load
> specifications") in the first place:)
>
>
> There is a missing abstraction that probably you get in Rowan or tODE with
> that project entry specification?
>
> Yes, tODE project entries are an implementation that I have been using for
> several years now and over time I have found some limitations in the tODE
> implementation that I am attempting to correct in the Rowan implementation
> ... The Rowan spec I originally referenced[1] is actually "load expression"
> that is the equivalent of a Gofer load expression ... I have classes for a
> Metacello-based "load expression" but I haven't gotten to the point where I
> have integrated Metacello into Rowan.
>
> [1] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston
>
> Because the reality is that personally I'm starting a new image every a
> couple of days, and having a specification for it would be much easier than
> locking here and there...
> I want just to specify "My project X at development time requires Y, Z, H
> and Z and H are subprojects".
> Then, he should realize he should lock Z and H for me.
>
> Yes this is exactly the problem I was dealing with in the early
> implementation of tODE and with project entries.
>
> You might want to look again at my FAST talk on "Dangerous Liaisons:
> Smalltalk, Files, And Git"[2] as I talk about "image clusters" that share a
> collection of project entries and the fact that each image needs to be able
> to have a private set of "project entries" ... now that you are
> experiencing the pain my talk might make more sense:)
>
> ... also I am thinking in terms of an "image specification" that is made
> up of a collection of Rowan "load specifications" ... Rowan has the notion
> of a Project Set and it is possible to load a set of projects. So it is not
> that big of a stretch to imagine a .ston image specification (collection
> load specifications) can be passed around and then customized if needed by
> individual developers and then project set can be used to create the image
> or images ....
>
>
> [2] https://www.youtube.com/watch?v=Ejmqs0xLvSk
>
>
> Now, If subprojects Z and H are in the same repository as X, that should
> not be complicated :).
> In Denis' case it could be more complicated...
>
> Right but once Denis gets his dependent projects cloned to local disk he
> can update each of the projects on his schedule by pulling later versions
> of the projects as he goes ... I lean to disk-based clones that can be
> shared by multiple images (an "image cluster")  ... tODE does not have the
> notion of image clusters, but I do have sets of images that are sharing a
> common set of projects where a number of those projects are on
> development-specific branches so Iknow that this concept makes sense ...
>
>
>
>> To share a specific configuration of development git repos, you need to
>> know that SHA anyway, so the image can produce a collection of project
>> entries with the SHA of the commit and those project entries can be
>> included in a bug report ...
>>
>> For Rowan[2], I am using a "load specification"[3], which is a second
>> generation project entry .... the Rowan work is still evolving ...
>>
>> Anyway, I think that putting the control of what is being used for
>> development completely in the developers hands and avoiding the need to
>> edit baselines is a good thing ... and I think that the idea of having
>> specifications that are shared by a cluster of images is a good way to  go
>> ...
>>
>> Dale
>>
>> [1] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seas
>> ide32.ston
>> [2] https://github.com/dalehenrich/Rowan
>> [3] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> <http://www.cnrs.fr>*
>
>
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>
>
>

Reply via email to