Dependency footprint

[dpwiz]

As a maintainer I would like to know which of my dependencies are having major impact on my downstream.
As a library developer I would like to know when adding a new dependency to my package would produce a spike in compilation time.
As a user I would like to know if my project build time would jump up when I add a new library.

Some libraries are small by themselves, but use something rather large (model case: interpolatedstring-perl6).
Some libraries are large, but widely used (model case: lens).

Depending on your project, you can use either of those with a negligible or rather dramatic impact.
I believe something useful can be divined from just the dependency graph between the packages.
Plugging a concrete package will allow to refine results wrt. already existing dependencies.
I can imagine that some script being run on a project can consult hypothetical Flora API endpoint and a local freeze file to tailor its results.

My personal example: I once pondered if I can add recursion-schemes dependency for my hedn package. I see some bits of Kmettverse in its deps, but on the other hand, I expect marginal costs to be on a "negligible" side, since those are parts of the lens package and it widely used already.

[tchoutri]

Okay from what I understand we can provide scores based different criteria:

• River score of a package
• Compilation resources required
• Probably lottery factor (CPAN computes it as The # people with an indexing permission on thep ackage who have released something to CPAN in the last 2 years (i.e. the # people likely able to release critical fixes in a timely manner))
• And for good measure why not something akin to Kwalitee?

[tchoutri]

@shadowcat-mst Are there any pitfalls that are known in the community regarding the CPAN-specific criteria I listed? Do you know if some of them proved to be red herrings with time? :)

[tdammers]

A couple unassorted thoughts on this.

First; for me personally, the most important bits of information would "which GHC versions does my package work on", and "are my version bounds actually correct" (i.e., does my package actually work against all versions within the declared bounds). I believe Hackage already has (or had?) something like this, but it's not widely known or advertised.

Beyond that, I think it would be great to get a more systemic view of a package in the context of a large, constantly evolving ecosystem - dependency graphs aren't stable, new package versions are published all the time, and each of them can potentially change the dependency graphs (both forward and reverse) of any package. It would be great to have tooling that can detect certain undesirable situations, such as:

• Dependencies stuck at old versions due to conflicting constraints (this is bad because old versions may have bugfixes, possibly critical / security-relevant ones)
• Overly lax upper bounds (makes things more likely to break in the future)
• Dependency resolution "bottlenecks" (situations where a dependency ends up constrained to an uncomfortably small number of versions - this is bad because it limits independent development, the very reason we specify version ranges in the first place)

And then I'd love to get this information not just about my own package, but also about any other packages that might be affected by my package.

And finally, it would be great to have a "what-if" tool, where you could play with hypothetical changes that you're considering, or that someone else might consider, like:

• What if I increase the upper bound of one of my dependencies - which packages will be affected? Will this solve any dependency problems? Introduce new ones? Break anyone else's packages?
• What if package X releases version Y - will this break my package? Will it break someone else's package due to something my package does? Will it fix any dependency problems that involve my package?
• What if a new GHC version is released - will my package work with that? Will my package prevent other packages from supporting this new version?

OTOH, download statistics don't interest me all that much, although they may be useful as a very crude proxy for gauging the practical impact of a potential or detected breakage. But one has to be careful with this, because there's going to be significant overlap between users of packages within the same dependency graph, so just adding up all the download counts is most likely going to be grossly inaccurate.

[tchoutri]

The "Package Statistics" project will track the ideas that can be implemented individually https://github.com/orgs/flora-pm/projects/10/