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?


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


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

There is a missing abstraction that probably you get in Rowan or tODE with
that project entry specification?
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.

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


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

Reply via email to