[23:16:51] <lifeless> ionelmc: so I closed the bug on mock because there wasn't a bug: a) the dependency is present (see requirements.txt which is reflected into setup's kwargs); b) pbr offers runtime services so its not inappropriate; c) pbr has a bug:- fine, that should be in the pbr bugtracker.
[23:17:36] <ionelmc> from my perspective that doesn't make sense
[23:30:02] <lifeless> I've filed https://bugs.launchpad.net/pbr/+bug/1483067 - thanks for the report about tht
[23:32:08] <lifeless> anyhow, the goal with mock is to keep maintenance overheads as low as possible. pbr is part of that. If there's a defect with pbr, I'm going to steer you to the pbr bug tracker to help address that. if there's a defect in the way mock uses pbr, thats obviously applicable to mock
[23:32:44] <lifeless> using pbr per se is not a defect though - pbr, while opinionated, is intended for use by people whereever it will help them
[23:33:00] <dstufft> I think it's silly to equate using pbr with Openstack (although it's come out of Openstack and you're most likely to find it's use by people who are at least tangently related to openstack). I have my gripes about parts of pbr (as lifeless knows :D) but I don't think it's wrong for any project to use it if they are happy with what it provides
[23:38:41] <ionelmc> lifeless: there's a typo here http://docs.openstack.org/developer/pbr/#usage
[23:41:41] <ionelmc> dstufft: lifeless: my issue with pbr is the complexity, and I've found no good place to understand what and why pbr does what it does. and it does so many things - that's what scares me
[23:41:49] <ionelmc> there's also the issue of overlap
[23:43:06] <dstufft> because people often want different things
[23:43:31] <dstufft> pbr does more than setuptools_scm
[23:43:37] <lifeless> noone has contributed patches to do other vcs's (and at one stage they would have been given pushback on that, I think the upstream community has grown [attitude, not size] since then.
[23:43:39] <dstufft> you may want more than what setuptools_scm does
[23:52:07] <dstufft> Yes, undocumented but deprecated behavior is quite common in Python
[23:52:19] <dstufft> both in Python the language and in the ecosystem
[23:52:30] <lifeless> ionelmc: so yes, the docs are what we're expecting folk to go off of
[23:52:54] <dstufft> it's a reasonable way to not break existing software but to not have new people use an old thing, and also keep the docs concise and easy to understand
[23:53:03] <ionelmc> i think this discussion is becoming fruitless :)
[23:53:03] <lifeless> its possible that we could delete OLSO_PACKAGE_VERSION entirely now, but there's still a risk of breaking someones script somewhere, and its nearly free to keep
[23:53:44] <ionelmc> lifeless: could you produce some sort of overview doc/article comparing pbr to the other solutions it overlaps with?
[23:54:56] <lifeless> ionelmc: possibly. I suspect I'd need to look into what has emerged over the last 4 years to be able to do so well.