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.
Yes the add button is awkwark. Christophe is often not using it via the tool menu.
* The opposite of the green-plus icon would be a red-minus icon rather than the trash-can icon.
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
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.
agree we should add the tool in the system so that we can use it as fast as possible.
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.
No you can really get a good understanding of the dependency. We should continue to address them. Often the system is not thought with layer and modularity in mind (for example all the inform: and cursorWhile: everywhere. I think that we should remove as much as possible as cursorWhile:. for example. Stef
cheers -ben