[WIP] Why oh why?

[theimowski]

#1959

TODO:

• recognize github dependencies
• show dependencies up to the top level
• option for displaying version and depending packages version constraints
• show the shortest path by default, give option to show all paths
• mark all direct dependencies in path
• reword "dependency path" -> "dependency chain", make the output more user-friendly
• what should be displayed when asking for a direct dependency, and what if it is not a top-level dependency?
• handle circular dependencies ?

Feedback welcome!

[cdrnet]

This will become very useful, thanks! Could it also provide some info on why a particular version is used (or what is effective version constraints are), if applicable?

[Stift]

When a package dependency is shown, do we show all dependencies up the dependency tree up to the top-level, only top level or only to the next level?
Could also be a command switch like --full

[forki]

@theimowski please keep posting screenshots if you change something. This is awesome

[theimowski]

will do, I'll also let know whenever I get to the point where it could be merged - possibly with not yet all features implemented

[isaacabraham]

Would it be worth making package id optional - so that it shows why all packages are in the lock file for a given group (although this might be a bit verbose)?

[theimowski]

@Stift I think it makes sense to show all deps up to the top level by default.
What I'm wondering is whether it makes sense to print all paths from the top level package, or just choose a shortest one? (see below e.g. Microsoft.Bcl.Build)

[forki]

Maybe show the shortest and say "and x more paths"?

[tommes]

Maybe (as a 2nd step) we couln't just ask for package id's, but also for artefacts - i.e. why is the dll/js/whatever in my output. In case I've overlooked that just ignore the comment.

[forki]

That would be brilliant

Am 14.10.2016 09:27 schrieb "Thomas Koch" notifications@github.com:

Maybe (as a 2nd step) we couln't just ask for package id's, but also for
artefacts - i.e. why is the dll/js/whatever in my output. In case I've
overlooked that just ignore the comment.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1960 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNNqWsjTTQN3r1hG2igLDMaTj3jFyks5qzy7JgaJpZM4KUnL8
.

[forki]

@tommes but it's probably hard to decide without reimplementing MSBuild logic

[Stift]

I think by package Id would be sufficient for the most use case.
If there are more than one path then, I'd like to have an option like -full or -all, if possible.
If a tree notation would be too complex I would recommend sth like ´Package1 >> Package2 >> Package3´
@theimowski Would it make sense to merge the trees, so that the output is more compact?

[forki]

If we merge the trees then we will get the lock file back

Am 14.10.2016 17:05 schrieb "Christian Fiebrig" notifications@github.com:

I think by package Id would be sufficient for the most use case.
If there are more than one path then, I'd like to have an option like
-full or -all, if possible.
If a tree notation would be too complex I would recommend sth like
´Package1 >> Package2 >> Package3´
@theimowski https://github.com/theimowski Would it make sense to merge
the trees, so that the output is more compact?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1960 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNKInm4QJfXA1ySiysueDfyEI7exUks5qz5otgaJpZM4KUnL8
.

[theimowski]

Can NuGets have cyclic dependencies? And if so does it resolve to paket.lock?

[theimowski]

How about this? I've grouped the paths by the top level dependency and if from a specific top level dep there are >1 paths, we show shortest by default.
This way we won't ignore multiple top-level deps

[forki]

I released it in alpha. please create new PRs to keep it going ;-)

[theimowski]

Alright! Can one continue work on the same branch and reopen PR in github or do i have to create new PRs?

[forki]

You can try to reopen. Not sure if this works.

Am 22.10.2016 17:51 schrieb "Tomasz Heimowski" notifications@github.com:

Alright! Can one continue work on the same branch and reopen PR in github
or do i have to create new PRs?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#1960 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNB4iTKN8Yg9uhKtq4re1_beW-mO2ks5q2jEAgaJpZM4KUnL8
.