filetree
filetree copied to clipboard
dalehenrich
Monticello dependency test case
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 ...
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 https://github.com/dalehenrich/filetree/issues/145.
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) ...
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
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?
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) ?
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 ...
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:)
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
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.