On 25 August 2015 at 11:49, Thomas Kluyver wrote:
> On Mon, Aug 24, 2015, at 04:30 PM, Robert Collins wrote:
>> c) write convoluted tricky code to workaround the bugs and differing
>> behaviour on 3.4 vs 3.5.
>
> I use unittest.mock from Python 3.4 on several packages, and it has not
> required co
On Mon, Aug 24, 2015, at 04:30 PM, Robert Collins wrote:
> c) write convoluted tricky code to workaround the bugs and differing
> behaviour on 3.4 vs 3.5.
I use unittest.mock from Python 3.4 on several packages, and it has not
required convoluted code. I would be very surprised if that code breaks
On Aug 25, 2015, at 11:30 AM, Robert Collins wrote:
>Except that that will break: mock in 3.4 vs 3.5 are different.
Then they aren't the same . So it sounds like it doesn't make sense to
remove python3-mock from Debian.
Cheers,
-Barry
pgpV2khUPaCtA.pgp
Description: OpenPGP digital signature
On 25 August 2015 at 11:23, Barry Warsaw 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 i
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 condition
On 25 August 2015 at 10:37, Barry Warsaw wrote:
> On Aug 25, 2015, at 10:03 AM, Robert Collins wrote:
>
>>On 25 August 2015 at 09:57, Barry Warsaw wrote:
>>...
>>> By all means, if there isn't any
>>> significant difference between a standalone package and what's available in
>>> the current sup
On Aug 25, 2015, at 10:03 AM, Robert Collins wrote:
>On 25 August 2015 at 09:57, Barry Warsaw wrote:
>...
>> By all means, if there isn't any
>> significant difference between a standalone package and what's available in
>> the current supported Python 3 version, let's not ship unnecessary binar
On 25 August 2015 at 09:57, Barry Warsaw wrote:
...
> By all means, if there isn't any
> significant difference between a standalone package and what's available in
> the current supported Python 3 version, let's not ship unnecessary binary
> packages.
Even at the cost of having to patch upstrea
On Aug 19, 2015, at 06:41 PM, Matthias Klose wrote:
>As a Debian developer you are duplicating code, and no, I don't think that
>providing this code under a different name is different enough to rectify
>distribution of this code in Debian.
In some cases however, the standalone library moves ahea
Just a quick follow-up I've been meaning to send.
On Jul 02, 2015, at 03:55 PM, Barry Warsaw wrote:
>As part of the 3.5 test rebuild I noticed an incompatibility with
>python3-enum, which I reported upstream. The response was: there's actually
>no reason to have a Python 3 version of enum in any
On 07/09/2015 12:25 PM, Robert Collins wrote:
> On 3 July 2015 at 08:29, Scott Kitterman wrote:
>
>> I think dropping these duplicates is the only thing that makes sense. For
>> reference, I dropped python3-ipaddr once python3.2 was gone (because 3.3 has
>> ipaddress, which does the same thing).
On Jul 09, 2015, at 10:25 PM, Robert Collins wrote:
>I don't have a view on other packages.
As it turns out, enum34 is actually renaming its public package name so it
won't conflict with the stdlib name. I may end up keeping the python3 variant
after all.
Cheers,
-Barry
--
To UNSUBSCRIBE, em
On July 9, 2015 7:39:15 AM EDT, Ian Cordasco wrote:
>On Jul 9, 2015 5:25 AM, "Robert Collins"
>wrote:
>>
>> On 3 July 2015 at 08:29, Scott Kitterman
>wrote:
>>
>> > I think dropping these duplicates is the only thing that makes
>sense.
>For
>> > reference, I dropped python3-ipaddr once python3
On Jul 9, 2015 5:25 AM, "Robert Collins" wrote:
>
> On 3 July 2015 at 08:29, Scott Kitterman wrote:
>
> > I think dropping these duplicates is the only thing that makes sense.
For
> > reference, I dropped python3-ipaddr once python3.2 was gone (because
3.3 has
> > ipaddress, which does the same t
On 3 July 2015 at 08:29, Scott Kitterman wrote:
> I think dropping these duplicates is the only thing that makes sense. For
> reference, I dropped python3-ipaddr once python3.2 was gone (because 3.3 has
> ipaddress, which does the same thing).
Where its a dupe sure.
unittest2, traceback2, linec
On July 2, 2015 3:55:30 PM EDT, Barry Warsaw wrote:
>As part of the 3.5 test rebuild I noticed an incompatibility with
>python3-enum, which I reported upstream. The response was: there's
>actually
>no reason to have a Python 3 version of enum in any version >= Python
>3.4.
>Since that's all we
>> So I'd argue that ‘python3-mock’ and the like do have a place in Debian:
>> they make it easier to follow the recommended strategy of having a code
>> base run unchanged on Python2 and Python 3.
As it turns out, it looks like upstream enum34 is going to rename the import
to 'enum34' so it won't
On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins
wrote:
> On 3 July 2015 at 11:44, Ian Cordasco wrote:
>> On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney
>> wrote:
>>> Barry Warsaw writes:
>>>
[…] there's actually no reason to have a Python 3 version of enum in
any version >= Python 3.4. [
On 3 July 2015 at 15:05, Ian Cordasco wrote:
> On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins
> wrote:
>> On 3 July 2015 at 11:44, Ian Cordasco wrote:
>>> On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney
>>> wrote:
Barry Warsaw writes:
> […] there's actually no reason to have a Pytho
On 3 July 2015 at 11:44, Ian Cordasco wrote:
> On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney wrote:
>> Barry Warsaw writes:
>>
>>> […] there's actually no reason to have a Python 3 version of enum in
>>> any version >= Python 3.4. […]
>>
>> Ian Cordasco writes:
>>
>>> Probably a silly question, bu
On 3 July 2015 at 11:40, Ben Finney wrote:
> Barry Warsaw writes:
>
>> […] there's actually no reason to have a Python 3 version of enum in
>> any version >= Python 3.4. […]
>
> Ian Cordasco writes:
>
>> Probably a silly question, but are other libraries like unittest2 also
>> being packaged for
On 3 July 2015 at 09:53, Ian Cordasco wrote:
> On Thu, Jul 2, 2015 at 2:55 PM, Barry Warsaw wrote:
>> As part of the 3.5 test rebuild I noticed an incompatibility with
>> python3-enum, which I reported upstream. The response was: there's actually
>> no reason to have a Python 3 version of enum i
On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney wrote:
> Barry Warsaw writes:
>
>> […] there's actually no reason to have a Python 3 version of enum in
>> any version >= Python 3.4. […]
>
> Ian Cordasco writes:
>
>> Probably a silly question, but are other libraries like unittest2 also
>> being packa
Barry Warsaw writes:
> […] there's actually no reason to have a Python 3 version of enum in
> any version >= Python 3.4. […]
Ian Cordasco writes:
> Probably a silly question, but are other libraries like unittest2 also
> being packaged for python3? Another library is mock. That was included
>
On Thu, Jul 2, 2015 at 2:55 PM, Barry Warsaw wrote:
> As part of the 3.5 test rebuild I noticed an incompatibility with
> python3-enum, which I reported upstream. The response was: there's actually
> no reason to have a Python 3 version of enum in any version >= Python 3.4.
> Since that's all we
As part of the 3.5 test rebuild I noticed an incompatibility with
python3-enum, which I reported upstream. The response was: there's actually
no reason to have a Python 3 version of enum in any version >= Python 3.4.
Since that's all we have now, maybe it makes more sense to just remove the
python
26 matches
Mail list logo
