The section titled "So Why Does Abstract and Concrete Matter?" on Donald's post explains pretty clearly why you can't have these two types of dependencies in the same file.

There is another discussion on the Pipfile repo about this that may also clarify things for you [0]. The example I posted there [1], which I'll post again here, is:

---

A project can only have 1 set of abstract dependencies (setup.py/pyproject.toml), but different users working with that project can have different sets of concrete dependencies (requirements.txt/Pipfile) which allow them to fulfill those abstract dependencies from PyPI mirrors, private package indexes, personal forks on GitHub, or somewhere else.

So if project Car depends on Engine (an abstract dependency), I can choose to install Car but grab Engine specifically from a fork I made on GitHub (a concrete dependency) that has some performance improvements. Meanwhile, someone else working at a big company that doesn't want to depend on external services to build and deploy their internal Python projects can choose to install both Car and Engine from their private package index as opposed to PyPI (another concrete dependency).

You can't merge these two types of dependencies together into one file without hampering people's ability to choose where to get their dependencies from.

---

According to another commenter on that issue [2], both Rust and Ruby have a similar split in how they specify dependencies.

[0] https://github.com/pypa/pipfile/issues/27

[1] https://github.com/pypa/pipfile/issues/27#issuecomment-26228...

[2] https://github.com/pypa/pipfile/issues/27#issuecomment-26226...