-
Hi! Thank you for this excellent website! Especially the reverse dependency feature is exciting! (Did you think about package metrics such as download rate? https://crates.io does a good job in that respect, I think.) I saw that packages show up as their own "Dependents" (should we use "Reverse dependencies"?). For example, the package I was a bit surprised about this feature! Is this behavior desired? Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
Hi @dschrempf!
Yes I have, and it would power the next version of the search engine. See #4
Looks to me like this should be a custom "ignore" rule, because Flora actually scans all the components of all the releases, and you'll see that your test suite actually depends on So, I don't think we should filter out every |
Beta Was this translation helpful? Give feedback.
-
It is great that you are working on package metrics! Yes the test suite dependency is correct: The test suite depends on the library in the package. However, this is most likely the case for all packages. In conclusion, filtering out the package seems like a good idea. In the longer run, I think one should distinguish between test or benchmark suite dependencies and dependents and library (or application) dependencies and dependents. For example, take the approach of |
Beta Was this translation helpful? Give feedback.
-
Not gonna lie, it's heavy work and I'll need all the help I can get on that. :) |
Beta Was this translation helpful? Give feedback.
-
Update: As of v1.0.6, packages are no longer shown as their own dependents. |
Beta Was this translation helpful? Give feedback.
Hi @dschrempf!
Yes I have, and it would power the next version of the search engine. See #4
Looks to me like this should be a custom "ignore" rule, because Flora actually scans all the components of all the releases, and you'll see that your test suite actually depends on
circular
: https://github.com/dschrempf/circular/blob/master/circular.cabal#L51 :)So, I don't think we should filter out every
test-suite
component, but we certainly can filter out the package name itself from its own dependents. :)