Add option "--exclude-dependencies" for "pip freeze" and "pip list"

[Mark-Joy]

1> Add option "--exclude-dependencies" for "pip freeze" and "pip list" as per feature request #10667 and #8981

Update:
2> Add option --user-requested for "pip freeze" and "pip list"
Refer requested status

[uranusjr]

TBH I am not very keen on adding this to pip. The problem is that what counts as dependency and what does not is a fundamentally subjective issue that pip is never going to really get right. If this gets in, we will face endless “bug reports” telling us we ought to have include some packages as dependencies but do not, or (if we do something to change the functionality to freeze some packages that are depended by another, with whatever logic) we should not have include a package when this flag is supplied. I am really not interested in taking this free puppy.

[pfmoore]

Good point. One reason I keep pushing the idea that "you can write a script to do this" is because it's (relatively) easy to write something that covers your specific needs, but as you say nearly impossible to write something that pleases everyone.

I'm largely indifferent to this, but I would want a pretty strong consensus from the pip maintainers that this was worth having before we merged it. I suspect we won't get that.

[Mark-Joy]

The problem is that what counts as dependency and what does not is a fundamentally subjective issue that pip is never going to really get right.

@uranusjr Can you elaborate on why couldn't pip get it right?
In source code, we have iter_dependencies to get the required packages. Isn't it by itself interpreting dependencies as packages that are required by the installed modules. So if there is any bug report, it should be on the installed modules itself, not pip. Maybe --exclude-required would be a better name?

[uranusjr]

One thing the current logic does not consider is extras. Should an environment containing Jinja2 and Babel be frozen into two separate lines, or just Jinja2[i18n]? I can easily imagine some would ask for the latter. Now you already need to complicate the implementation quite a lot to cover that. And if we always emit Jinja2[i18n], people who use the two packages separately (i.e. not using Jinja2’s i18n features, but use Babel for UI translation) would be unsatisfied because they never pip install Jinja2[i18n], only pip install Jinja2 and pip install i18n separately, and expect they to be separate entities. Platform dependencies is another issue. Again, what counts as dependency and what does not is a fundamentally subjective issue. What you do here works for your use case, and you probably don’t care about what was described above, but other people will, and pip maintainers are forced to as well.

[lrustand]

I came here from google trying to find a way to make a reasonable requirements.txt. I don't use requirements.txt files often, but when I do I feel it is full of "spam". Say I install three packages in a venv for a small script, then if I later come back to my script and have forgotten which packages I needed to install I could run pip freeze, but this results in all kinds of crap.

It is hard as a user to figure out what are the "hard" or direct requirements for a specific project, and what is third party dependencies. Very often when I find a cool script or project the requirements.txt contains versions that are incompatible with each other or other things that makes it impossible to run pip install -r requirements.txt, thus making it hard or impossible for me as a normal user to actually use the script.

I want to see only the three packages that were explicitly installed, and I'm guessing this is what most other people that wants this feature wants too. So what I propose is to call it --explicitly-installed, or --top-level or something. Please stop making arguments against adding what should have been the most basic use case for pip freeze.

[uranusjr]

It’s not spam, the dependencies are included so the file more accurately reflects the environment. Without those lines, a requirements file would not be able to reproduce the installation when a new version of a dependency is released (and not excluded by the dependant, which is often the case). This kind of requirements files has its use cases, but pip freeze and pip list are not designed for them.

[pypa-bot]

Hello!

I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the master branch into this pull request or rebase this pull request against master then it will eligible for code review and hopefully merging!

[Mark-Joy]

Update:
Rebase commit:
1> Add option "--exclude-dependencies" for "pip freeze" and "pip list"

Add commit:
2> Add option --user-requested for "pip freeze" and "pip list"
Refer requested status

[Mark-Joy]

@lrustand
You can use my fork option --user-requested for --explicitly-installed and --exclude-dependencies for --top-level