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. 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. > - not run the Ironic unit tests. Nope. But anyway, that's MHO. Cheers, -Barry
pgpkdZ2ym1xdB.pgp
Description: OpenPGP digital signature
