Open fendor opened 4 years ago
If this feature is a welcome addition to cabal-plan, I would be happy to provide a PR for it.
Yes, please! :-)
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?
It’s a good start.
On 11. Apr 2020, at 0.39, fendor notifications@github.com 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.
Similar to
nix
, addwhy-depends
command, to show why you depend on a package.Workflow:
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:
If this feature is a welcome addition to
cabal-plan
, I would be happy to provide a PR for it.