If you think packaging is a matter of configuration, then PBR makes a lot of sense. It gives you a config file that you simply fill out so you don't have to worry yourself about the code.

I've used both PBR and setup.py quite a bit and I personally prefer PBR since there's less things I need to debug when things go wrong.

Trying to paper over the (real) problems with the Python packaging toolchain by generating setup.py from a config file strikes me as a vanity project.

You fail to give any examples as to why it would be an improvement too, aside from a very vague "less things I need to debug when things go wrong". Which I'd argue against since now I also need to potentially worry about things going wrong in PBR, which is one more thing I need to debug. This seems to be the general theme with pbr, there's no clear reasons for why it's better and when asked about it you get these kind of hand-wavy answers.

If you actually have some concrete examples as to what it improves and why I'm all ears.

    with codecs.open('requirements.txt') as f:
        requirements = f.read().splitlines()
    ...
    install_requires=requirements,

In case anyone sees this, at a minimum you need to use

  from pip.req import parse_requirements
  parse_requirements('path/to/requirements.txt')

from my understanding, when you build the package, your computer extracts the relevant required packages, and sends up that data to pypi, which then in turn sends that data back to users when they install

At least thats how I think it works

if you used any other package manager, it would need to resolve dependencies from the additional info in the package index, resulting in pip being downloaded and installed before the desired package is installed

If you control requirements.txt, there is nothing "not robust" about parsing it in setup.py.

You can also use `dependency_links` in your setup.py to specify this, which allows deps on github etc.

Define my dependencies

- setup.py

- requirements_dev.in

run piptools pip-compile to generate a locked set of dependencies

- requirements.txt

- requirements_dev.txt

It gives me some of the benefit of Rust's Cargo.toml / Cargo.lock in the python world (and actually respects all package's dependency version declarations unlike other tools like pyup).