[Hackage] #499: develop tool to analyse package dependency splits

#499: develop tool to analyse package dependency splits ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Looking at packages on hackage as a whole we often see cases where different packages require mutually incompatible versions of some dependency. The most notable cases at the present time are parsec 2 vs 3, HaXml 1.13 vs 1.19, HTTP 3000 vs 4000 etc. What we want to know is, which dependencies are the divisive ones. In such cases is there a clear winner? Which are the most divisive packages? A divisive package is one where looking at the packages that depend on it, the intersection of versions constraints is empty. That is we cannot configure all the other packages on hackage without them disagreeing about the devisive package. When we say all, we really only mean the latest recommended version of each package, not all versions of all packages. Looking at the packages depending on a divisive package we may see a clear consensus that can resolve the issue if we ignore the minority. Frist we must discover the 'camps', that is the sets of packages that can agree on versions of the dependency. For example it might be simply two camps, `pkg < 3` vs `pkg >= 3`. Then for each camp we score it based on the importance of the packages in that camp. The importance of packages is calculated separately (based on downloads and importance of dependents). The camp with the biggest score wins. Some packages are more divisive than others. A package is more divisive if the the loosing camps are still quite important. That corresponds to excluding many packages from the maximal consistent package set. It would be useful to make a ranking of the most divisive packages because these correspond to cross-package problems that need resolution in a more coordinated fashion and their impact is bigger. It would also be useful to track trends in the balance of the camps for divisive packages. It may be that such splits can be naturally resolved. If there is a clear trend then we can simply make that the de-facto recommendation. Imagine a summary page on hackage for platform managers to see what the most divisive packages are and the trends for each one. It would help them and maintainers to make decisions on recommendations for dependencies. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/499 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#499: develop tool to analyse package dependency splits ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): See also ticket #500 for another tool that would use this. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/499#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage