Le 4 sept. 2015 à 18:23, Ben Coman a écrit : > 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".
You were clear. Maybe I was not. I meant I will open an issue to add the dependency anlayzer packages as part of the default Pharo image. > 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. I never used this UI because I find easier to just right-click on a selected package in Nautilus and select 'browse dependencies ...'. I will take a look at this UI to enhance it a bit. > 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. It is seen as a dependency because if you want to load AST-Core, containing an extension method on TBehavior class packaged in Traits, and Traits is not in the system, it will fail. We could imagine optional extension methods, i.e. only loaded in the system if the class extended is present but it is not like that now. >> >>> 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 At this time, not a lot. It is mostly when you know that a code will not be executed. >> 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. Yes, that will be done very soon. > 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. it will be the first step to check regressions from the dependency point of view. It can be done with a CI job if dependency analysis is published for each image. > Perhaps even it could provide live > advice through integration with Quality Assistant. It is what I want at the end. When you update a method or a class, run a dependency check against the current version and the version about to be saved. To reach this point, each package needs to have its dependencies specified. It will come ... Thanks for the feedback
smime.p7s
Description: S/MIME cryptographic signature
