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
