PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Sunday the 9th of August, 2015

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[23:12:11] <lifeless> ionelmc: can you file that reproducer for pbr intrusion on the pbr bug tracker please?
[23:14:46] <ionelmc> lifeless: i'm not sure i'm gonna be able to deal with another early bug close ;)
[23:14:58] <lifeless> ionelmc: thats clearly a bug
[23:15:05] <lifeless> pbr isn't meant to alter anything on non-pbr projects
[23:15:31] <ionelmc> i find that sort of behavior unpolite
[23:15:41] <lifeless> how thats happening I don't know yet - my attempts to reproduce it have been unsuccessful so far
[23:15:49] <ionelmc> try it on pip
[23:15:55] <lifeless> just about to
[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:18:09] <lifeless> which bit?
[23:18:25] <ionelmc> i didn't ask to remove pbr from mock either, even if it's surprising
[23:18:28] <lifeless> doesn't happen in pip either... are you trying this from a git tree ?
[23:18:37] <ionelmc> git yes
[23:18:39] <lifeless> ah
[23:18:46] <lifeless> ok, I think that narrows it down a bit
[23:18:59] <ionelmc> maybe you need to remove your egg-info
[23:19:05] <ionelmc> setuptools caches it
[23:19:25] <lifeless> there it goes
[23:19:26] <lifeless> writing pbr to pip.egg-info/pbr.json
[23:19:27] <lifeless> no
[23:19:33] <ionelmc> ?
[23:19:34] <lifeless> it doesn't happen in downloaded sdists
[23:19:37] <lifeless> only in git trees
[23:19:48] <lifeless> I was trying with freshly unpacked tarballs
[23:20:28] <ionelmc> why is mock using pbr anyway? is it an openstack project now?
[23:20:42] <lifeless> pbr is generally useful
[23:20:58] <lifeless> mock is using pbr because its in git and needs the things pbr offers
[23:21:40] <ionelmc> one has to wonder if that really waranted, it's not like mock is on a openstack-style release process
[23:21:41] <ionelmc> is it?
[23:22:49] <ionelmc> so from that perspective pbr has no use in mock
[23:22:51] <lifeless> I really don't understand the question. Its code, in git, that gets released. pbr helps with that.
[23:23:01] <lifeless> How much help do you need to use a helper library?
[23:23:15] <lifeless> OpenStack has precisely zero to do with this.
[23:23:26] <ionelmc> depends
[23:23:33] <lifeless> It's like asking 'why does pip use py.test. Is it really warranted?'
[23:23:43] <ionelmc> it's not that pbr does too little to be generally applicable
[23:23:52] <ionelmc> it's that is too complex to have around
[23:23:56] <ionelmc> that's my problem
[23:24:11] <lifeless> Can you be more specific about that?
[23:24:16] <ionelmc> and you can see it right now - why is it monkeypacking setuptools?!
[23:24:32] <lifeless> it doesn't monkeypatchsetuptools
[23:24:42] <lifeless> it uses the standard setuptools extension interface that all setuptools plugins use.
[23:24:56] <ionelmc> are you 100% sure? :)
[23:25:55] <ionelmc> http://git.openstack.org/cgit/openstack-dev/pbr/tree/pbr/core.py#n150
[23:26:29] <ionelmc> i don't know if that happens all the time or not
[23:26:46] <lifeless> thats inside the pbr() keyword for setuptools
[23:26:54] <lifeless> triggered by pbr=True in your setup() call
[23:28:33] <ionelmc> lifeless: what features of pbr does mock use?
[23:28:44] <ionelmc> just the version thing?
[23:29:04] <lifeless> version calculations from git, version injection into sphinx build metadata, runtime version querying
[23:29:41] <lifeless> declarative dependency handling
[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:38:45] <ionelmc> "distribute"
[23:41:11] <lifeless> historical for sure
[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:41:57] <lifeless> overlap with ?
[23:42:04] <ionelmc> like for example, overlap with setuptools_scm
[23:42:13] <dstufft> Well, pbr existed before setuptools_scm
[23:42:21] <dstufft> so it'd be more correct to say that setuptools_scm overlaps with pbr
[23:42:22] <ionelmc> and the dozen other tools you can use to manage the version
[23:42:28] <lifeless> sure, it overlaps. You can use setuptools_scm if you prefer :).
[23:42:50] <dstufft> but, nobody I think says you have to like pbr, but that doesn't make it a bug for someone else to like and use pbr
[23:42:53] <ionelmc> so why do we have setuptools_scm then :)
[23:43:04] <lifeless> pbr only supports git
[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:43:47] <dstufft> or you may not
[23:43:56] <ionelmc> now I'm looking at the source again, it doesn't have the openstack CI env var handling anymore?
[23:44:04] <lifeless> the what now?
[23:44:38] <ionelmc> dunno, a year ago or so, it has some weird handling for some weird env vars
[23:44:44] <ionelmc> s/has/had/
[23:44:46] <dstufft> the PBR_VERSION or whatever?
[23:45:15] <ionelmc> iirc it was something with OPENSTACK
[23:45:33] <ionelmc> that were i got the openstack-project impression from
[23:45:42] <dstufft> (Also, I blame lifeless and Monty Taylor for why I know stuff about pbr)
[23:45:55] <lifeless> pbr was created by consolidating setup.py glue from openstack projects
[23:46:08] <lifeless> its single largest group of users and contributors is OpenStack
[23:46:16] <ionelmc> nope
[23:46:19] <ionelmc> it still does
[23:46:23] <ionelmc> what he hell is "OSLO_PACKAGE_VERSION"
[23:46:42] <ionelmc> this is why i consider pbr an openstack project
[23:46:54] <lifeless> it was the old name for PBR_VERSION
[23:47:09] <lifeless> you'll not its in the lower precedence path there, and its not documented.
[23:48:48] <ionelmc> that's what i dislike - undocumented behavior
[23:49:42] <dstufft> You must not like Python much
[23:49:57] <lifeless> ionelmc: so the old thing that noone is meant to use should be documented ?
[23:50:30] <ionelmc> ok now you make it sound ridiculous
[23:51:25] <lifeless> I think dstufft is gently teasing you
[23:51:54] <ionelmc> lifeless: is not that 'old legacy thing' - i mean, how would i know if that the only one
[23:52:03] <ionelmc> trust issue i guess
[23:52:05] <ionelmc> :)
[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.