4 ms·
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
by atarian 9y ago
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.
- daenney 9y agoI 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.
- deleted 9y ago[deleted]
- ak217 9y agoThat'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.