News for hackers. Stuff that matters.
Re:Packaging Python software with pbr by atarian on Wednesday September 13, 2017 @02:57PM (#15241444)
Prefacing with "all it seems to do" makes you sound like you haven't actually used PBR, which could also explain why you don't understand why people prefer PBR to setup.py.

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.

Re:Packaging Python software with pbr by ak217 on Sunday September 17, 2017 @09:47PM (#15272811)
That's the problem, there's more things you need to debug, since PBR does not get rid of any of the problems that you encounter with setuptools or pip, but adds its own.

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.

Re:Packaging Python software with pbr by daenney on Thursday September 14, 2017 @08:21AM (#15247193)
I have, in 2 different projects and rejected PRs to introduce it in another three. Because "all it seems to do" is move the problem to a different location.

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.