On 25 August 2015 at 11:23, Barry Warsaw <ba...@debian.org> wrote: > On Aug 25, 2015, at 10:45 AM, Robert Collins wrote: > >>Lets take Ironic. While it supports Python 2.7+ and 3.4+ it will >>depend on 'mock' for unit testing. > > That's not unreasonable, and different upstreams will have different policies, > but if it was *my* upstream package, I'd probably do a conditional import so > that unittest.mock were used if available, falling back to mock if not.
Except that that will break: mock in 3.4 vs 3.5 are different. Lots of bugs fixed in 3.5. Upstreams have to choose: a) use 'mock' everywhere which has all the fixes. b) use 'mock' everywhere except *3.5 and only 3.5*. c) write convoluted tricky code to workaround the bugs and differing behaviour on 3.4 vs 3.5. > If it's easy to patch upstream to do this, then it seems an acceptable > approach to take. I wouldn't say it's *required* (which is why I'm not sure a > blanket policy is appropriate for us). > >> - patch Ironic to use unittest.mock on Python 3.5 > > That would be my first preference, and I'd also submit the patch to upstream. > >> - patch the stdlib to make 'mock' be an alias to unittest.mock > > Nope. > >> - include 'python3-mock' as a binary package > > That's not unreasonable for Debian either. > > I'll note another thing that perhaps makes the enum34 case different. It > exports the package under the same name in both the standalone version and in > the stdlib, so there *really* is no difference between the two. That's not > the case with unittest.mock/mock. It certainly makes it a lot harder to tell them apart :). And yeah, very hard to consume it. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud