Re: Removing some python3-* packages
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 version = Python 3.4. Since that's all we have now, maybe it makes more sense to just remove the python3-enum package from Debian. Which is what I'm going to do. I've interacted with upstream and there's just no reason for us to be shipping a Python 3 version of enum34, especially in Stretch given our current and future supported Python 3 versions. I'll be uploading a new version of enum34 that deletes python3-enum34 asap. py3porters, please keep this in mind and don't add it back. It'll ftbfs anyway and I'll close any related bug as won't fix. In general, I think we'll just have to take similar situations on a case-by-case basis. For packages which provide additional functionality not in stdlib Python 3, it may still make sense to provide a python3- version of the package. Cheers, -Barry pgp_2BLSpo3X4.pgp Description: OpenPGP digital signature
Re: Removing some python3-* packages
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 ahead of the stdlib, because they have hugely different release cycles. They may eventually catch up every 18 months (when a new Python is released), but in the meantime the divergence might be needed by dependent packages. So I'm not sure a blanket policy is useful. 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. Cheers, -Barry
Re: Removing some python3-* packages
On 25 August 2015 at 09:57, Barry Warsaw ba...@debian.org 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 upstream projects? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud
Re: Removing some python3-* packages
On Aug 25, 2015, at 10:03 AM, Robert Collins wrote: On 25 August 2015 at 09:57, Barry Warsaw ba...@debian.org 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 upstream projects? Sorry, I'm not sure what the question means. Cheers, -Barry pgpcXi3cKf4sQ.pgp Description: OpenPGP digital signature
Re: Removing some python3-* packages
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
Re: Removing some python3-* packages
On 25 August 2015 at 11:49, Thomas Kluyver tho...@kluyver.me.uk 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 convoluted code. I would be very surprised if that code breaks when run under Python 3.5. If it works with mock 1.3 (in stretch) and with unittest.mock from 3.4, then you're fine. Very much depends on the size and variety of your codebase, whether you will have an issue or not. But it doesn't take 'works for me' to invalidate the point: it requires 'works for *everyone*' - and while you haven't experienced the faults yourself that in no way invalidates the experience of folk that have experienced it. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud
Re: Removing some python3-* packages
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 wink. So it sounds like it doesn't make sense to remove python3-mock from Debian. Cheers, -Barry pgpV2khUPaCtA.pgp Description: OpenPGP digital signature
Re: Removing some python3-* packages
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 when run under Python 3.5.
Re: Removing some python3-* packages
On 25 August 2015 at 10:37, Barry Warsaw ba...@debian.org wrote: On Aug 25, 2015, at 10:03 AM, Robert Collins wrote: On 25 August 2015 at 09:57, Barry Warsaw ba...@debian.org 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 upstream projects? Sorry, I'm not sure what the question means. Lets take Ironic. While it supports Python 2.7+ and 3.4+ it will depend on 'mock' for unit testing. If Debian has only Python 2.7 and 3.5 and wants to build Ironic for only Python 3.5 - which is a reasonable thing, then 'mock' is needed (because Ironic depends on 'mock'). We could: - patch Ironic to use unittest.mock on Python 3.5 - patch the stdlib to make 'mock' be an alias to unittest.mock - include 'python3-mock' as a binary package - not run the Ironic unit tests. Perhaps to you 'thing we package X uses library Y' implies 'binary package X is uncessary' - but the thing is that 'binary package X' may not be a significant difference vs the Python version in Debian at the time - even if there are significant differences vs older still upstream-supported Python versions - which is what the developer ecosystem will be referencing. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud
Re: Removing some python3-* packages
On 07/09/2015 12:25 PM, Robert Collins wrote: On 3 July 2015 at 08:29, Scott Kitterman deb...@kitterman.com 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, linecache2, mock are not duplicates of the functionality in 3.4 - they are backports of things in 3.5 (to all pythons). And they will shortly have more than 3.5 itself has in it, as they are rolling backports: what lands in 3.6 will go into them. So I don't think removing them makes sense. I think it does. You are confusing here your role as an upstream Python author, as a third party upstream developer and as a Debian developer. As an upstream Python author you are actively forking the Python standard library. I don't think I read any PEP about these forks. As a third party upstream developer (I assume openstack in this case) you want to provide a way to port this stack to Python3. Having these modules available for Python2 makes sense, but using these modules for Python3 is just a lazy way. 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 the past, the use of modules added in the standard library was handled like: try: import module in stdlib except ImportError: import separate module as module in stdlib From my point of view this should be done with your python3 modules as well. As a service to the community you could provide appropriate snippets like the above as well. maybe adjusted for different Python versions. Further, if your forks gain popularity, there's no way out to remove these at some time, because people will rely on these forks, having no way out of using these modules, obsoleting the versions in the standard library, and people will be stuck with your forks. So please remove the python3 versions at least for Debian. I will definitely ask for their removal, and will add appropriate Conflicts/Replaces once 3.5 becomes the default in Debian. Matthias
Re: Removing some python3-* packages
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, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150709094914.2a937...@limelight.wooz.org
Re: Removing some python3-* packages
On Jul 9, 2015 5:25 AM, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 08:29, Scott Kitterman deb...@kitterman.com 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, linecache2, mock are not duplicates of the functionality in 3.4 - they are backports of things in 3.5 (to all pythons). And they will shortly have more than 3.5 itself has in it, as they are rolling backports: what lands in 3.6 will go into them. So I don't think removing them makes sense. I don't have a view on other packages. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ3HoZ0a9rSSAc-zv+7qhP+0n-wMGQ=hrm__togtuesopuk...@mail.gmail.com Further, should API compatibility also be considered? If I remember correctly ipaddress in the stdlib and ipaddr have similar but not exactly identical APIs
Re: Removing some python3-* packages
On 3 July 2015 at 08:29, Scott Kitterman deb...@kitterman.com 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, linecache2, mock are not duplicates of the functionality in 3.4 - they are backports of things in 3.5 (to all pythons). And they will shortly have more than 3.5 itself has in it, as they are rolling backports: what lands in 3.6 will go into them. So I don't think removing them makes sense. I don't have a view on other packages. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ3HoZ0a9rSSAc-zv+7qhP+0n-wMGQ=hrm__togtuesopuk...@mail.gmail.com
Re: Removing some python3-* packages
On July 9, 2015 7:39:15 AM EDT, Ian Cordasco graffatcolmin...@gmail.com wrote: On Jul 9, 2015 5:25 AM, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 08:29, Scott Kitterman deb...@kitterman.com 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, linecache2, mock are not duplicates of the functionality in 3.4 - they are backports of things in 3.5 (to all pythons). And they will shortly have more than 3.5 itself has in it, as they are rolling backports: what lands in 3.6 will go into them. So I don't think removing them makes sense. I don't have a view on other packages. -Rob Further, should API compatibility also be considered? If I remember correctly ipaddress in the stdlib and ipaddr have similar but not exactly identical APIs I dropped python3-ipaddr only after all the reverse-depends were ported to use ipaddress from the stdlib. So I agree it should be considered and it was. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2bbc7d70-567d-4d8b-ab9c-06bce1915...@kitterman.com
Re: Removing some python3-* packages
On July 2, 2015 3:55:30 PM EDT, Barry Warsaw ba...@debian.org 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 have now, maybe it makes more sense to just remove the python3-enum package from Debian. There may be similar packages which are fairly straight backports of Python 3 packages. For those that are no longer necessary, what do you think about removing the python3-* version of the binary package? It seems like a bit of a regression given that we want Python 3 versions of our libraries, but in cases like this it probably makes sense. Thoughts? -Barry 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). Scott K
Re: Removing some python3-* packages
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 conflict with built-in enum. It's still not Python 3.5 compatible yet (the test suite fails) but maybe that makes removing it a moot point. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150703084829.6e6a3...@limelight.wooz.org
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. 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. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/can-kwu1os1+grzrbcx41jsbs2uqgwxukmw2usgmgfo4safd...@mail.gmail.com
Re: Removing some python3-* packages
On 3 July 2015 at 11:44, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. 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. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. See my prior mail. I will be backporting all the changes in mock from the stdlib to the mock standalone lib in the near future. I have upload acls from Michael Foord for PyPI and I'm not afraid to use them to fix it up - if you wanted to prep a narrow patch to fix 3.4 then please do so here - https://github.com/testing-cabal/mock -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj3hoz1emwkf5st9wburfxv0ffe-ufn+jkugcvvd2ttarnn...@mail.gmail.com
Re: Removing some python3-* packages
On 3 July 2015 at 09:53, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 2:55 PM, Barry Warsaw ba...@debian.org 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 have now, maybe it makes more sense to just remove the python3-enum package from Debian. There may be similar packages which are fairly straight backports of Python 3 packages. For those that are no longer necessary, what do you think about removing the python3-* version of the binary package? It seems like a bit of a regression given that we want Python 3 versions of our libraries, but in cases like this it probably makes sense. Thoughts? -Barry Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. Is that being packaged for python3 on Debian as well? I know it's nice to have the libraries available on both, but mock for example stopped working on python3.4 since it's solely maintained in the stdlib now. It doesn't make sense to package that for both. (Keep in mind, I'm just an observer and I haven't checked if those examples are already packaged for Py3) So, unittest2 is *explicitly* targeted at 3.5, 3.4, 3.3, 3.2, 2.7, 2.6. Its not 'unittest for 2.6', its unittest for not-running-from-hg. Same for traceback2, linecache2, and shortly, when I get a day to fix it up, mock. All those IMO should remain packaged, because the stdlib is moving on them, and folk like being able to use the new shiny without waiting years. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj3hoz1l2x-w0sx4igypngxorh6-wrn+bciducntjrpnvk+...@mail.gmail.com
Re: Removing some python3-* packages
Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. 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. -- \ “Nullius in verba” (“Take no-one's word for it”) —motto of the | `\ Royal Society, since 1663-06-30 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85lheyqgb3@benfinney.id.au
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 11:44, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. 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. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. See my prior mail. I will be backporting all the changes in mock from the stdlib to the mock standalone lib in the near future. I have upload acls from Michael Foord for PyPI and I'm not afraid to use them to fix it up - if you wanted to prep a narrow patch to fix 3.4 then please do so here - https://github.com/testing-cabal/mock Will do in the next couple weeks. I had chatted with Michael about it on Twitter and he expressed no interest in supporting it. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAN-Kwu1cv9BxZWb3TAte_WXe2QEkabZe8ZOd32BAL3u8=4g...@mail.gmail.com
Re: Removing some python3-* packages
On 3 July 2015 at 11:40, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. I hope you mean 'import unittest2' - and great, thats the intent. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. unittest2 also has new features in it for python 3.2, 3.3, 3.4, and will soon have new features for 3.5 as well. 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. +1. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ3HoZ04F=s8af224xl6bceapg8hqeo+tpv+cdfvgkyowji...@mail.gmail.com
Re: Removing some python3-* packages
On 3 July 2015 at 15:05, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 10:03 PM, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 11:44, Ian Cordasco graffatcolmin...@gmail.com wrote: On Thu, Jul 2, 2015 at 6:40 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Barry Warsaw ba...@debian.org writes: […] there's actually no reason to have a Python 3 version of enum in any version = Python 3.4. […] Ian Cordasco graffatcolmin...@gmail.com writes: Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. One consideration is: What code is written to be Python 2 and Python 3 compatible from the same code base, which achieves this by importing a module which is backported to Python 2? In some of my code I'm doing ‘import unit2’ to have features from that library available in Python 2 code. Since those features are all in Python 3's standard library, the case could be made that ‘python3-unit2’ is pointless; but against that is the fact that a Python 3 ‘unit2’ package means that ‘import unit2’ will work the same on both runtime versions. 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. Just to be clear, trying to use mock on 3.4 is thoroughly broken. If you can install python3-mock right now and use it in 3.4, then y'all must be carrying patches to make it work. The last 3.x version that mock works on is 3.3. That clearly doesn't have a place on a debian with python 3.5 as the version of python 3 included, unless you're planning on supporting packages for python 3.3 as well that will generate a numerous amount of bugs for you. See my prior mail. I will be backporting all the changes in mock from the stdlib to the mock standalone lib in the near future. I have upload acls from Michael Foord for PyPI and I'm not afraid to use them to fix it up - if you wanted to prep a narrow patch to fix 3.4 then please do so here - https://github.com/testing-cabal/mock Will do in the next couple weeks. I had chatted with Michael about it on Twitter and he expressed no interest in supporting it. AIUI he's pretty busy stuck in golang land these days, so that doesn't surprise me. He added me to PyPI etc specifically so I can do / facilitate this :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj3hoz3bpqwfwfda3hec93_2krx1ccvaweyhezelnsugtqx...@mail.gmail.com
Removing some python3-* packages
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 python3-enum package from Debian. There may be similar packages which are fairly straight backports of Python 3 packages. For those that are no longer necessary, what do you think about removing the python3-* version of the binary package? It seems like a bit of a regression given that we want Python 3 versions of our libraries, but in cases like this it probably makes sense. Thoughts? -Barry pgpFaj8FPL6Dr.pgp Description: OpenPGP digital signature
Re: Removing some python3-* packages
On Thu, Jul 2, 2015 at 2:55 PM, Barry Warsaw ba...@debian.org 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 have now, maybe it makes more sense to just remove the python3-enum package from Debian. There may be similar packages which are fairly straight backports of Python 3 packages. For those that are no longer necessary, what do you think about removing the python3-* version of the binary package? It seems like a bit of a regression given that we want Python 3 versions of our libraries, but in cases like this it probably makes sense. Thoughts? -Barry Probably a silly question, but are other libraries like unittest2 also being packaged for python3? Another library is mock. That was included in the stdlib in 3.3. Is that being packaged for python3 on Debian as well? I know it's nice to have the libraries available on both, but mock for example stopped working on python3.4 since it's solely maintained in the stdlib now. It doesn't make sense to package that for both. (Keep in mind, I'm just an observer and I haven't checked if those examples are already packaged for Py3) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAN-Kwu0t=SKW=9gH6HYGLZZNW76rvchnZVzp8Hm6C1T=ux4...@mail.gmail.com
