All that said, I have no clue what Pipfile is adding. The rationale appears to be that people sometimes don't use requirements.txt properly? Can one of the very enthusiastic commentators explain their enthusiasm?
That hasn't been settled yet. It's being actively discussed [0].
> Or is the idea to eventually get rid of setup.py?
Yes, a replacement for setup.py has already been agreed on in PEP 518 [1]. It's called pyproject.toml.
https://pypi.python.org/pypi/flit
Looks quite nice, a flat .ini file for specifying deps, though it only builds wheels.
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...