Top level dependencies don't show when it is already listed as a subdependency when freezing

[Daniel A]

Not sure how common of a use case this is -

We have a script to verify the top level dependencies using pipdeptree. However, if a higher level dependency includes another dependency, the lower one is not listed as a top level dependency in the tree.

We can change our script to no longer do this, but was wondering if this was valid bug before proceeding.
It could also be a change in behavior in pip itself, but not sure.
The requirements.txt are slightly different, but future is listed as a top dependency in both files.

Simplest Example
pipdeptree 1.0.0 + Python2.7 (Notice that future is listed as a top dependency)

$ pipdeptree -w silence -f -p oic,future
future==0.18.2
oic==0.15.1
  alabaster==0.7.12
  Beaker==1.11.0
    funcsigs==1.0.2
  cryptography==3.3.2
    cffi==1.14.5
      pycparser==2.20
    enum34==1.1.10
    ipaddress==1.0.23
    six==1.15.0
  future==0.18.2
  Mako==1.1.1
    MarkupSafe==1.1.1
  pycryptodomex==3.9.8
  pyjwkest==1.4.2
    future==0.18.2
    pycryptodomex==3.9.8
    requests==2.25.0
      certifi==2021.5.30
      chardet==3.0.4
      idna==2.10
      urllib3==1.26.5
    six==1.15.0
  requests==2.25.0
    certifi==2021.5.30
    chardet==3.0.4
    idna==2.10
    urllib3==1.26.5
  six==1.15.0
$ pipdeptree -w silence -f -p future
future==0.18.2

pipdeptree 2.2.1 + python3.9

$ pipdeptree -w silence -f -p future,oic
oic==1.2.1
  Beaker==1.11.0
  cryptography==3.3.2
    cffi==1.14.5
      pycparser==2.20
    six==1.15.0
  defusedxml==0.6.0
  Mako==1.1.3
    MarkupSafe==2.0.1
  pycryptodomex==3.9.8
  pyjwkest==1.4.2
    future==0.18.2
    pycryptodomex==3.9.8
    requests==2.26.0
      certifi==2021.10.8
      charset-normalizer==2.0.7
      idna==3.3
      urllib3==1.26.7
    six==1.15.0
  requests==2.26.0
    certifi==2021.10.8
    charset-normalizer==2.0.7
    idna==3.3
    urllib3==1.26.7
  typing_extensions==4.0.1
$ pipdeptree -w silence -f -p future
future==0.18.2

[Vineet Naik]

There's indeed a difference from 1.0.0 to 2.x version of pipdeptree that I had not noticed.

But the 1.0.0 behaviour is quite arbitary IMO. To be consistent with the default behaviour of pipdeptree ie. when run without any flags - the right way to fix it is by making the --all flag work along with the -p flag.

It should be quite straightforward to fix it but I am not sure if I would be able to push the fix soon. Will try by next weekend.

Thanks for reporting!