Added nested json output to pipenv graph command

[PieterjanMontens]

Hello all,

This is a small contribution to solve a particular need I had. I made the necessary changes (exposing pipdeptree's --json-tree*) in a fork (didn't have contributor status before, let me know if I should do a new PR from the base fork), filtered the BAD_PACKAGES from the output and added a small test, based on the work that had been done before.

• pipenv's shipped version of pipdeptree has this feature

[uranusjr]

I feel we should be more graceful here. There are two possible interfaces (taking Click’s limitations in mind):

• Use the current options, but --json --json-tree simply means --json-tree.
• Add a --type option (instead of --json-tree). --json --type=flat outputs the current --json result, which --json --type=true uses --json-tree. We can even implement a flat output for the non-JSON variant. If --type is not specified, the current behaviour is the default (flat for JSON, nested for non-JSON).

[PieterjanMontens]

There's indeed room to be more graceful, I considered that also (or even with--flat & --nested options), but opted for the --json-tree option because:

• pipenv graph is mostly an interface to pipdeptree;
• abstracting pipdeptree's arguments away would add a layer of confusion (in it's usage but also for developments down the road);
• future versions of pipdeptree could add more arguments, which could conflict with pipenv's own graph commands;
• it would mean more code will have to be maintained.

I also considered exposing --graph-output, but that didn't seem justified in a Dev & CI/CD environment.

[PieterjanMontens]

Another option, if Click's version accepts it, is to forward all unknown options to pipdeptree's wrapper, which would reduce the load of exposing it's functionalities, and facilitate integration of future versions of that package.

Edit: current included Click version is 6.7, so yes, it's a possibility

[uranusjr]

Sounds reasonable to me. In this case, however, maybe it would be better to just hand the flags to pipdeptree without validation? pipdeptree would happily accept --json --json-tree --reverse, but just silently ignore some of them.

[PieterjanMontens]

That would be the case, yes. However, we can specify in the help text how the flags behave, and who overpowers whom.

closed->reopened->closed->reopened: whoopsy, is that usual ?

[PieterjanMontens]

Thinking of it, forwarding unknown options is not really desirable: it would mean the options wouldn't be defined in click, meaning they wouldn't appear in the --help, meaning more confusion and just plain obfuscation... let's not do that ;)

[uranusjr]

Yeah I agree. Registering the options to Click is a good idea, the only doubt I have is whether we should perform additional checks. It’s really minor though, let’s just merge it and come back to this if someone complains.

[PieterjanMontens]

OK, great 👍

[kennethreitz]

simplicity is better than functionality.

[PieterjanMontens]

I like this quote, from Don Norman:

“The argument is not between adding features and simplicity, between adding capability and usability, The real issue is about design: designing things that have the power required for the job while maintaining understandability, the feeling of control, and the pleasure of accomplishment.”