You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the analysis of how heavily a package relies on external dependencies, we can use the include_external_packages argument in the build_graph. This analysis can be used to determine which modules are affected when a dependency is removed/replaced or made optional.
Standard library imports are not relevant for this analysis, as we cannot remove them anyway.
I would like to be able to exclude them, preferably when building the graph. Alternatively, they can be filtered out later.
For this use case, I would suggest exposing the build graph arguments through impulse so that users can perform this analysis quickly from the command line.
The text was updated successfully, but these errors were encountered:
I think I could get behind this proposal providing it doesn't introduce too much complexity, since as you say we could, alternatively, move this up a level and filter things out by libraries that use Grimp. Feel free to submit something if you'd find it helpful.
For the analysis of how heavily a package relies on external dependencies, we can use the
include_external_packages
argument in the build_graph. This analysis can be used to determine which modules are affected when a dependency is removed/replaced or made optional.Standard library imports are not relevant for this analysis, as we cannot remove them anyway.
I would like to be able to exclude them, preferably when building the graph. Alternatively, they can be filtered out later.
For this use case, I would suggest exposing the build graph arguments through
impulse
so that users can perform this analysis quickly from the command line.The text was updated successfully, but these errors were encountered: