Hi Ben, Le 4 sept. 2015 à 17:04, Ben Coman a écrit :
On Fri, Sep 4, 2015 at 9:13 PM, Christophe Demarey <christophe.demarey@inria.fr> wrote:
Hi,
I created a job to automatically generate a report of the Pharo image dependencies as well as current bootstrap dependencies. You can find them here:
https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTML... https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTML...
There are a lot (too many) dependencies but you can focus on some of them with the search field. Dependencies inside orange boxes are dependencies that are there but that we ignore (for example, an example method adds an extra-dependency). It should be fixed later but is not a problem for now. Ignored dependencies are declared in the package manifest in #ignoredDependencies. Dependencies inside red boxes are dependencies we want to remove for the bootstrap. For now, they are listed in the bootstrap dependency report.
People that are willing to help to have a more modular Pharo could first take a look at the bootstrap dependency report and check dependencies that we should cut. Once we know, we can open issues on fogbugz in the 'bootstrap category' and update manifests accordingly. To investigate more deeply dependencies, you can use the DependencyAnalyzer (in the Pharo Catalog) to actually check dependencies (inheritance, reference, extension, traits, message send).
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. In a second step, I will introduce rules to check dependencies.
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. 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.