Add --no-deps support for use in requirements files

[pikhovkin]

Please reopen #3985.
This opportunity is one of those that are rarely used, but very useful when it is needed.

[pfmoore]

The reasons for closing it remain valid, IMO. Do you have any new arguments to add? "Very useful when it is needed" isn't very specific.

[pikhovkin]

This is particularly useful if you need to install two packages that have dependencies on different versions of a third package.

There is a third-party base package (pkg1), which depends on Flask. I need to support the fork of pkg1 (pkg2), which depends on Django.
There are many third-party packages that depend on pkg1 (but this third-party packages not depend on Flask). I do not need to install pkg1 when installing those packages with pkg2.

[pikhovkin]

it would not be bad to realize such use

some_pkg1[no-deps]
some_pkg2
some_pkg3[no-deps]==0.1

as a pattern for --no-deps needs for specific packages in requireemnts file

[chrahunt]

Python packaging in general does not support these kinds of relationships, where one package can "satisfy" a certain requirement for other packages without all the other dependent packages knowing about it. As a result, any change we make to support it will be pip-specific and not participate in the wider packaging ecosystem. We try to avoid that as much as possible because:

1. pip-specific changes tend to get less oversight and feedback than changes that are brought to a wider audience (like via a PEP)
2. if the pip-specific behavior is standardized later, it will probably not look exactly the same, so there would be backwards-compatibility concerns which makes maintenance harder
3. in general we prefer fewer configuration options supported in the least number of places, to reduce the number of combinations and unexpected behaviors we need to consider when providing support and making changes - it would be better if this was part of the metadata itself and things would "just work" in the way we expect

I would suggest bringing up your use case on discuss.python.org/c/packaging and ask how to approach it. The feedback may be direct (e.g. host your own version of pkg2 as pkg1 on a private repository and give instructions to use that instead) or indirect (e.g. push for Python packaging in general to support these kinds of relationships). Either way I'm sure you'll get great suggestions and some thought put towards your idea.

I hope that helps. I will close this now, but if you do create a thread please don't hesitate to drop a link in a comment here.