[Feature Request] Add why-depends command

[fendor]

Similar to nix, add why-depends command, to show why you depend on a package.

Workflow:

$ cabal-plan why-depends exe:foo containers
 └─ foo-1.0
    [foo-1.0:exe:"foo"]
    └─ some-package-2.7.1
       └─ containers-0.6.2.1 ┄┄

If package is multiple times in the dependency closure, every path is shown.

An extension would be to show why this version was chosen.
Some idea for the output format:

$ cabal-plan why-depends exe:foo containers --show-constraints
some-package: containers ^>= 0.6.2.1

Final version constraint:
containers ^>= 0.6.2.1

Chose containers-0.6.2.1

If this feature is a welcome addition to cabal-plan, I would be happy to provide a PR for it.

[hvr]

If this feature is a welcome addition to cabal-plan, I would be happy to provide a PR for it.

Yes, please! :-)

[fendor]

I have a design question. Currently, I can produce the following output:

cabal-plan-0.6.2.0
 ├─ aeson-1.4.7.1
 │  ├─ attoparsec-0.13.2.4
 │  │  ├─ containers-0.6.2.1
 │  │  ├─ scientific-0.3.6.2
 │  │  │  ├─ binary-0.8.7.0
 │  │  │  │  └─ containers-0.6.2.1 ┄┄
 │  │  │  ├─ containers-0.6.2.1 ┄┄
 │  │  │  ├─ hashable-1.3.0.0
 │  │  │  │  └─ text-1.2.4.0
 │  │  │  │     └─ binary-0.8.7.0 ┄┄
 │  │  │  └─ text-1.2.4.0 ┄┄
 │  │  └─ text-1.2.4.0 ┄┄
 │  ├─ containers-0.6.2.1 ┄┄
 │  ├─ hashable-1.3.0.0 ┄┄
 │  ├─ scientific-0.3.6.2 ┄┄
 │  ├─ text-1.2.4.0 ┄┄
 │  ├─ th-abstraction-0.3.2.0
 │  │  └─ containers-0.6.2.1 ┄┄
 │  ├─ unordered-containers-0.2.10.0
 │  │  └─ hashable-1.3.0.0 ┄┄
 │  └─ uuid-types-1.0.3
 │     ├─ binary-0.8.7.0 ┄┄
 │     ├─ hashable-1.3.0.0 ┄┄
 │     └─ text-1.2.4.0 ┄┄
 ├─ containers-0.6.2.1 ┄┄
 └─ text-1.2.4.0 ┄┄

for lib:cabal-plan and I asked why it depends on containers.
I re-use the logic from cabal-plan info, in particular from dumpPlanJson.

The logic avoids re-printing units that have already been printed. Is that nice UX?

[phadej]

It’s a good start.

…

On 11. Apr 2020, at 0.39, fendor ***@***.***> wrote:  I have a design question. Currently, I can produce the following output: cabal-plan-0.6.2.0 ├─ aeson-1.4.7.1 │ ├─ attoparsec-0.13.2.4 │ │ ├─ containers-0.6.2.1 │ │ ├─ scientific-0.3.6.2 │ │ │ ├─ binary-0.8.7.0 │ │ │ │ └─ containers-0.6.2.1 ┄┄ │ │ │ ├─ containers-0.6.2.1 ┄┄ │ │ │ ├─ hashable-1.3.0.0 │ │ │ │ └─ text-1.2.4.0 │ │ │ │ └─ binary-0.8.7.0 ┄┄ │ │ │ └─ text-1.2.4.0 ┄┄ │ │ └─ text-1.2.4.0 ┄┄ │ ├─ containers-0.6.2.1 ┄┄ │ ├─ hashable-1.3.0.0 ┄┄ │ ├─ scientific-0.3.6.2 ┄┄ │ ├─ text-1.2.4.0 ┄┄ │ ├─ th-abstraction-0.3.2.0 │ │ └─ containers-0.6.2.1 ┄┄ │ ├─ unordered-containers-0.2.10.0 │ │ └─ hashable-1.3.0.0 ┄┄ │ └─ uuid-types-1.0.3 │ ├─ binary-0.8.7.0 ┄┄ │ ├─ hashable-1.3.0.0 ┄┄ │ └─ text-1.2.4.0 ┄┄ ├─ containers-0.6.2.1 ┄┄ └─ text-1.2.4.0 ┄┄ for lib:cabal-plan and I asked why it depends on containers. I re-use the logic from cabal-plan info, in particular from dumpPlanJson. The logic avoids re-printing units that have already been printed. Is that nice UX? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.