Dependency details do not show test-suite dependencies

[amigalemming]

Currently, in this example the dependencies of the test-suite are not shown:
https://hackage.haskell.org/package/lapack-0.2.1/dependencies

Maybe related to #789.

[grayjay]

#572 is also related.

[hvr]

To extend my former criticism about this feature: we can add this to the details UI, and reduce the clutter effect by means of making the less-relevance of test-suite dependencies apparent by means of appropriate CSS styling so it is shown in a less salient way. Or alternatively, by having an expandable collapsed section for the non-primary components.

[amigalemming]

On Wed, 23 Jan 2019, Herbert Valerio Riedel wrote: To extend my former criticism about this feature: we can add this to the details UI, and reduce the clutter effect by means of making the less-relevance of test-suite dependencies by means of appropriate CSS styling so it is shown in a less salient way.

If the users clicks on details he wants to see the details, won't he? If I don't see test-suite dependencies in the details I will assume that there is no test-suite, at all.

[phadej]

test-suites is a component type, we don't show many.

Currently dependencies page shows the a public library, and executables. E.g. if there are no proper sections, and internal libraries are shown then on
https://hackage.haskell.org/package/haddock-library-1.6.0/dependencies there would be attoparsec and it would look like an executable. Note how in lapack case, lapack-economic is implicitly known to be an executable, not a test-suite or benchmarks!

There should be clear sections:

• a library if exists
• internal (and soon public) libraries
• foreign libraries
• executables
• test-suites
• benchmarks

I think if there are section headers, we don't need to collapse test-suites or benchmarks. (I also hope we get per-component solving soon enough, so executables become non-primary components as well).

As a (somewhat mandatory) bonus, dependencies to internal libraries should be visually distinguishable as well.

[DanBurton]

Bump & +1 to @phadej 's "somewhat mandatory bonus": it would be nice if we didn't have internal libs listed in the dependency list; they are a broken link, and accidentally serve to hide what dependencies actually go into the lib.