Packaging with pyproject.toml vs requirements.txt?

From python testing with pytest:

For so many projects, packaging makes way more sense. However, this process (using requirement.txt) is common for web frameworks like Django and projects using higher-level packaging, such as Docker. In those cases and others, requirements.txt files are common and work fine.

  1. What exactly is higher-level packaging? I interpreted as high abstraction, easy to use, ready to go package.
  2. So isn’t it contradictory projects using higher-level packaging having requirement.txt? Because requirement.txt requires the users to manually pip install themselves. That doesn’t sound like higher-level packaging that’s easy to use, ready to go.

“higher level packing” in this case means that it isn’t python-level packing: docker doesn’t just contain the .py files, it also contains the python interpreter, the web server and other non-python applications. It doesn’t necessarily mean “easier to use” or “higher abstraction”.

pyproject.toml and requirements.txt solve different problems. The former is for defining a package (including name, author, build tool, …) and abstract dependencies, the latter is only for defining dependencies, and commonly concrete dependencies at that.

So isn’t it contradictory projects using higher-level packaging
having requirement.txt? Because requirement.txt requires the users
to manually pip install themselves. That doesn’t sound like
higher-level packaging that’s easy to use, ready to go.

Just to address this one point, requirements.txt doesn’t necessarily
mean manual installation. There are build backends which can read
requirements.txt files and turn them into Requires-Dist entries in
the resulting wheel’s METADATA file.