Pip with requirements.txt is never fine. It's always the wrong answer to any problem you may think you are solving with it. The problem is it's a very commonly given wrong answer, so, people are used to it.
The reason why it's the wrong answer is this:
You intend for your project to be deployed somehow somewhere. So, you do need a process to find the pieces of the project you are working on to put them where you are deploying them, be it a Docker image, a Python package, an RPM etc. But, pip + requirements.txt doesn't produce any of that. At best, you may hope to have it as an intermediary step in your process.
Now, a very important piece of your deployment is the code you wrote. That's something that's not in the requirements.txt. You sort-of have "pip install -e ." to do this, but it's awfully bad for this purpose because instead of actually installing anything, it's a wrapper around "setup.py develop", which, in turn doesn't install anything, but modifies Python's path where it searches for installed packages. This has a lot of bad / unintended consequences. For example, if you accidentally introduced a dependency on an artifact on your filesystem, it may or may not translate properly into your deployment environment. This is especially bad when you need to use Python code linked with some native libraries, but on your system and on deployment system they are found in different places. It may result in you confusing the libraries (and versions) you think you are using with those actually being used.
In order to avoid all of that, a better way is to create a distributable Python package (i.e. Wheel) and install that, but Wheel has its own way of specifying dependencies, which has nothing to do with requirements.txt. So, you either just don't need that, or try to combine the two somehow...
----
Bottom line: I package couple dozens Python packages for internal use. Those I have full control over don't have requirements.txt and don't use pip at all. They are easy to install and to test, portable between different environments etc. There are teams which produce their own Python packages which I have to package, and in many cases I wasn't able to convince them to abandon the bad (but popular) practices s.a. using pip or / and requirement.txt. This is a constant source of problems when it comes to dependency management. But, authors are convinced they are doing it right...