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
<mailto: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/Seaside32.ston
<https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside32.ston>
[2] https://github.com/dalehenrich/Rowan
<https://github.com/dalehenrich/Rowan>
[3]
https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston
<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_
*Web:* _http://guillep.github.io_
*Phone: *+33 06 52 70 66 13
