On Fri, Sep 4, 2015 at 11:18 PM, Christophe Demarey <[email protected]> wrote: > Hi Ben, > > Le 4 sept. 2015 à 17:04, Ben Coman a écrit : >> >> I tried the Dependency Analyzer. First a minor point, it wasn't >> obvious how to invoke it. I expected to see "Dependency Analyzer" in >> the tools but its not there. I think I correctly guessed it was >> "Package Dependencies Browser", but it would be better to match the >> catalog name. > > ok, I will fix that. > I will also add the analyzer in the system.
Sorry I'm (easily) confused - when you say "also" makes me think you are referring to "Package Dependencies Analysis". I only meant that if "Package Dependencies Browser" is the entry point, it would be better named "Dependency Analyzer". I did not have an opinion on whether "Package Dependencies Analysis" should be added to the menu (but maybe thats not what you meant.) > In a second step, I will introduce rules to check dependencies. btw, I'm not sure how much gloss you'd like to put on the Package Dependencies Browser, but just some immediate thoughts: * It feels awkward having the <Add package> button at the top and the <Add all> button at the bottom. It would be nicer if the first was also at the bottom on the same line (i.e. half the width). Same with the <remove...> buttons. * The opposite of the green-plus icon would be a red-minus icon rather than the trash-can icon. In Package Dependencies Analysis, taking for example "(AST-Core --> Dependent packages : 15 | Dependencies : 134 (+ 14 extension dependencies)" I see method Traits > TBehavior >> #parseTreeFor: whose extension protocol is *ast-core. This to me doesn't seem a dependency. > >> The sample dependency I looked at from bootstrap-dependency-report.html >> was Collections-Streams --> Tool-Transcript >> which seems to be due to only single method "Generator class>>examplePrimes". >> So should this be coloured orange by marking it in #ignoredDependencies ? > > The clean solution is to have a package Collections-Streams-Example with this > method. > It depends how we want to be strict with that. I can live with no additional > package and the dependency added in #ignoredDependencies. > There are so many wrong dependencies in the system that I will prefer at a > first step to put dependencies introduced by example methods or settings by > example as ignored dependencies because they will not be called. Are examples the only (or majority) kind of ignoredDependencies ? If there is a significant number of other kinds, it might be useful to split the examples out > We could fix that in a second step if we want and let us focus on stronger > dependencies. > > Thanks for helping. > > PS: Even for people not having time to clean the system, when you contribute > code to the image, pleas check that you do not introduce a dependency from a > low-level package to a higher level package. It is not obvious to catch but > for example, check that you do not introduce a dependency to UI packages when > the package could work without UI. Even with my best intentions, I think the long term reality is that the workflow delay of installing Dependency Analyzer to do this will inhibit me doing this. When working on issues I always start with a fresh/latest build. As a tool to facilitate one of Pharo's goals, perhaps it could be integrated into the Image and be prominently displayed on the top level World menu to encourage its use. Now I guess it will be hard to identify an introduced dependency just by looking at a one shot report after a modification. It would help if this could be compared to a prior snapshot stored in the image produced during the CI builds. Perhaps even it could provide live advice through integration with Quality Assistant. cheers -ben
