Re: Removing some python3-* packages
On 25 August 2015 at 11:23, Barry Warsaw <barry@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 <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud
Reply to: