Monticello dependency test case

[dalehenrich]

Monticello files have a dependency mechanism and there appears to be code in FileTree that is supposed to preserve package dependencies, but I don't believe that I have a test case, so I can't be sure that it still works ...

[ThierryGoubier]

Le 17/02/2015 05:01, Dale Henrichs a écrit :

Monticello files have a dependency mechanism and there appears to be
code in FileTree that is supposed to preserve package dependencies, but
I don't believe that I have a test case, so I can't be sure that it
still works ...

Hi Dale, I'm using test case 26 to test the dependencies. But I would
need probably more.

But I'm starting to see suspicious behavior from Monticello, as if
dependencies were an afterthought (and the interaction between
repositories and Monticello on dependencies a bit of a mess). I need to
check more.

—
Reply to this email directly or view it on GitHub
#145.

[dalehenrich]

But I'm starting to see suspicious behavior from Monticello, as if
dependencies were an afterthought (and the interaction between
repositories and Monticello on dependencies a bit of a mess). I need to
check more.

Well, I don't know what suspicious behavior you are seeing, but I found Monticello dependencies to be very rigid and unforgiving to the point where Metacello was invented as a replacement for package dependencies (and other things) ...

[ThierryGoubier]

Le 17/02/2015 22:31, Dale Henrichs a écrit :

Well, I don't know what /suspicious behavior/ you are seeing, but I
found Monticello dependencies to be very rigid and unforgiving to the
point where Metacello was invented as a replacement for package
dependencies (and other things) ...

Unforgiving? Yes and no. Yes because Monticello records very precisely
the dependency, and no because it seems to happily refer to a full
all-repositories search for the dependencies sitting in the same
repository in the first place :( (which allow naming mistakes to take
place :()

The suspicious behavior I see is linked to stranger things. It seems,
for example, that a package copy with dependencies does not call the
store dependencies API entry on the repository, but instead store them
by hand before storing the parent package (and, of course, this is where
you understand why there is some code checking if the dependency is not
already in the repository before writing it).

Even the test case 26 in FileTree is strange and writes the dependent
package by hand...

More to come soon once I get my way through it :)

Thierry

[ThierryGoubier]

Confirmed: a 'Copy' in the Monticello GUI does not save dependencies :(

save

    self pickRepository 
        ifNotNil: [ :ea | 
            self version dependencies do: [ :each | ea storeVersion: each resolve ]. 
            ea storeVersion: self version ]

Instead it forces the save of each dependency in standard mode (#storeVersion:).

This is ridiculous. How are we supposed to handle that at the repository level?

[ThierryGoubier]

Hi @dalehenrich , another question:

Is it normal that, with a chain of dependencies (AAA depends on BBB, BBB itself depending on CCC), writing AAA moves all dependencies to AAA and removes them from BBB (i.e. upon reloading, AAA depends on BBB and CCC, and BBB has no dependencies... unless BBB was written independently, as it would happen along certain paths) ?

[dalehenrich]

This is the rigid part ... from my perspective there is a very narrow range of use cases where Monticello dependencies are useful ... in the git universe you are better off with a BaselineOf and independently save packages as you want ...

[dalehenrich]

regarding the shifting dependencies ... I never really played a lot with Monticello dependencies ... at the time I was very interested in conditional loading of packages and Monticello dependencies doesn't do that ... I just remember that in order to save one package, I needed to have all of the packages loaded ... otherwise things went haywire ... with Metacello I've never looked back:)

[ThierryGoubier]

Le 18/02/2015 22:24, Dale Henrichs a écrit :

regarding the shifting dependencies ... I never really played a lot with
Monticello dependencies ... at the time I was very interested in
conditional loading of packages and Monticello dependencies doesn't do
that ... I just remember that in order to save one package, I needed to
have all of the packages loaded ... otherwise things went haywire ...

It seems there is something like that. Messy anyway. When trying stuff I
get errors all over the place.

with Metacello I've never looked back:)

This was also my feeling. Now, given Pharo's direction, should we
suggest deprecating Monticello dependencies and use baselines or
configurations instead?

Still, in the current state, packages with dependencies have that
"project" concept: save the topmost package and everything is saved
along (except intermediate versions of the dependencies, which breaks
merges and force people to save or copy those intermediate versions by
hand) (i.e. Pharo use of SLICES).

I don't know how it would work with Metacello, unless you use git, or
tools such as snapshotcello? and versionner.

Thierry

[dalehenrich]

On 2/18/15 1:33 PM, Thierry Goubier wrote:

Le 18/02/2015 22:24, Dale Henrichs a écrit :

regarding the shifting dependencies ... I never really played a lot with
Monticello dependencies ... at the time I was very interested in
conditional loading of packages and Monticello dependencies doesn't do
that ... I just remember that in order to save one package, I needed to
have all of the packages loaded ... otherwise things went haywire ...

It seems there is something like that. Messy anyway. When trying stuff I
get errors all over the place.

with Metacello I've never looked back:)

This was also my feeling. Now, given Pharo's direction, should we
suggest deprecating Monticello dependencies and use baselines or
configurations instead?
Eventually ... the prerequisite for that is to put "all" of the pharo
sources under git and baselines ... then I think you can have the moral
equivalent of slices when you create an issue branch and then merge your
changes in ...

configurations aren't quite convenient enough and merging projects at
the configuration level is not available ... so you need to use a
baseline and then leverage git ...

Still, in the current state, packages with dependencies have that
"project" concept: save the topmost package and everything is saved
along (except intermediate versions of the dependencies, which breaks
merges and force people to save or copy those intermediate versions by
hand) (i.e. Pharo use of SLICES).
If all of pharo's packages were in a single git repository managed by
one or more baselines, then a slice is just a branch of the repository
... and merging is dead simple ...

I don't know how it would work with Metacello, unless you use git, or
tools such as snapshotcello? and versionner.

I'm not sure what you are concerned about here ... I am suggesting
that git be used because Monticello does not have a way to manage
multi-package merges ... it's a natural for git ...

I've gone all-in with git, because I was facing the prospect of
duplicating all of the git functionality using ConfigurationOf ... I was
delighted when I found that I didn't have to implement and maintain that
functionality.