Yes, we need to seriously tackle this… without safe-guards (tests, for example), this will never work. Even tools would be nice to show dependencies...
On 13 Jan 2014, at 15:17, Pavel Krivanek <[email protected]> wrote: > Hi, > > if we remove Monticello package X, we should firstly remove packages that > extend the package X. I tried to play with a code that could give me such > order. Here it is: > > all := (MCWorkingCopy allManagers collect: #packageName). > > deps := Dictionary new. > all do: [:packageName | > | package | > package := (RPackageSet named: packageName). > deps at: packageName put: (package extensionMethods groupedBy: [ :m | > (Smalltalk classOrTraitNamed: m className) package packageName ]) keys ]. > > depsList := deps associations asOrderedCollection. > resolveBlock := [:a | a value isEmpty ]. > hasResolved := depsList select: resolveBlock. > notResolved := depsList reject: resolveBlock. > > ordered := hasResolved collect: [:a | a key ]. > > [ foundDeps := notResolved select: [ :a | ordered includesAll: a value ]. > notResolved := notResolved copyWithoutAll: foundDeps. > ordered addAll: (foundDeps collect: [:a | a key]). > foundDeps isEmpty ] whileFalse. > > ordered. > > > However, a lot of packages (156) cannot be removed because of cyclic > dependencies. You can see them together with count of references from other > packages with this code: > > notResolvedNames := (notResolved collect: [:a | a key ]). > ((notResolved collect: [:a | a key -> > (notResolved select: [:b | b value includes: a key]) size]) > asSortedCollection:[:a :b | a value <= b value]) > > The result is that we need to remove cyclic dependencies for this packages: > 'Kernel' 'Morphic-Base' 'Polymorph-Widgets' 'Tools' > Then the removing order can be computed. To check that try to modify previous > code: > > resolveBlock := [:a | a value isEmpty or:[#('Kernel' 'Morphic-Base' > 'Polymorph-Widgets' 'Tools') includes: a key] ]. > > I think we should add it as a release test too. > > Cheers, > -- Pavel > > > >
