Re: favouring Python3 in the Debian policy
On Wed, May 7, 2014 at 10:45 PM, Matthias Klose wrote: > Attached is a proposed change to the Debian Python policy to focus on Python3 > within the distribution. The intent is to document and start a large journey > towards one Python stack in Debian. This is unlikely to happen for jessie+1, > but > we should state the plan now so that it doesn't come later as a surprise. I'd like to suggest: A bits from Debian Python mail on d-d-a mentioning this. lintian tests, pedantic level for now. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6E5m6yJbFGDuzinuRVYqzraLGX+xT8R88xNPPP=eue...@mail.gmail.com
Re: favouring Python3 in the Debian policy
On Wed, May 7, 2014 at 4:59 PM, Barry Warsaw wrote: > On May 07, 2014, at 02:29 PM, Thomas Kluyver wrote: > >>This fork looks like it's actively maintained, and has a recent release on >>PyPI (as suds-jurko): >>https://bitbucket.org/jurko/suds > > There seems to be quite a few forks on PyPI: > > https://pypi.python.org/pypi?%3Aaction=search&term=suds&submit=search > > to name a few: > > suds-fc 0.4.1 5 Lightweight SOAP client > suds-jurko 0.6 5 Lightweight SOAP client (Jurko's fork) > suds-philpem 0.4.3 5 Lightweight SOAP client (philpem's > fork-and-merge) > suds-py3 1.0.0.05 Lightweight SOAP client > suds-vingd 0.4.35 Lightweight SOAP client (philpem's > fork-and-merge) > > > Does anybody know anything about these? Jurko's seems to claim Python 3 > compatibility on its Bitbucket page. > > -Barry > The jurko fork was the one I was working with when attempting the port to suds. I never made it to testing under python3. Regards, Jordan Metzmeier -- 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/cad758rikzxcqzoytdrsh+40sz4zoy9joggu1--ld9guecef...@mail.gmail.com
Re: favouring Python3 in the Debian policy
On Wed, May 7, 2014 at 4:11 PM, Paul Tagliamonte wrote: > On Wed, May 7, 2014 at 5:01 PM, Steve Langasek wrote: >> FWIW, while I think getting the python policy to recommend Python3 is a good >> step forward, I think it's more important that we make sure the base system >> is leading by example. As described on debian-devel[1], there seem to be >> some porting blockers before we can migrate from python to python3 in the >> standard install. >> >> [1] https://lists.debian.org/debian-devel/2014/04/msg00784.html > > Ugh, suds strikes again. > > If I had more time to blow, I'd likely try a run at something SUDS API > compatible in Python 3. Won't happen any time soon for me, but it's > something I will eternally praise someone over. > > So many people have tried to forward-port the SUDS codebase, > apparently it's *bad*. I do not consider suds to be the issue here. Currently the python-debianbts library uses SOAPpy. I opted to attempt to port the codebase to suds rather than port SOAPpy to python3. I have worked with a multitude of SOAP libraries in a few different languages and I have found suds to be easy to use and very efficient in comparison to other options. If you want to see a *bad* SOAP library codebase, have a look at python-zsi. In order to even get started with the port, I had to write a WSDL. I was very surprised to find a SOAP service that didn't expose one. Luckily, some of the work had already been done for an Emacs plugin which I was able to use as a base. The XML I was unable to get suds to produce in a call was XML that I would have otherwise never expected to be correct for a SOAP request. Let's take the get_usertag() method as an example, which the documentation says takes an email address and a list of tags. This is what I expect with an array of something in SOAP (usually there is a wsdl to tell exactly what it expects): foo foo bar What debbugs expects: foo foo bar It doesn't care about the names of the tags, it only cares about order. Since the first example matches the SOAP specification for arrays and the later does not[1], I consider debbugs to be broken, not suds. [1] http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383522 Regards, Jordan Metzmeier -- 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/cad758rhesybhjhenzumk4y6o8qjean6skexbvfyqng5v3ky...@mail.gmail.com
Re: favouring Python3 in the Debian policy
On May 07, 2014, at 02:29 PM, Thomas Kluyver wrote: >This fork looks like it's actively maintained, and has a recent release on >PyPI (as suds-jurko): >https://bitbucket.org/jurko/suds There seems to be quite a few forks on PyPI: https://pypi.python.org/pypi?%3Aaction=search&term=suds&submit=search to name a few: suds-fc 0.4.1 5 Lightweight SOAP client suds-jurko 0.6 5 Lightweight SOAP client (Jurko's fork) suds-philpem 0.4.3 5 Lightweight SOAP client (philpem's fork-and-merge) suds-py3 1.0.0.05 Lightweight SOAP client suds-vingd 0.4.35 Lightweight SOAP client (philpem's fork-and-merge) Does anybody know anything about these? Jurko's seems to claim Python 3 compatibility on its Bitbucket page. -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/20140507175920.55526...@anarchist.wooz.org
Re: favouring Python3 in the Debian policy
On Wed, May 07, 2014 at 11:43:24PM +0200, Matthias Klose wrote: > Am 07.05.2014 23:01, schrieb Steve Langasek: > > On Wed, May 07, 2014 at 10:15:37PM +0200, Matthias Klose wrote: > >> Am 07.05.2014 17:27, schrieb Barry Warsaw: > + ++ + > Applications should use > Python3, and should not be + packaged for Python2 as well. + > > >>> Maybe also that system scripts written in Python should be Python 3 and > >>> not Python 2. I'd add the clarity just because I'm not sure folks > >>> think of such system scripts as "applications". > >> proposing a separate item. > >> Command line scripts, packaging tools, tools used by Debian outside > >> the archive, etc. should use Python3, and should not be packaged for > >> Python2. > > I don't think scripts "outside the archive" are in scope for the python > > policy; > thas was "tools outside the archive". Debian has some infrastructure > written in Python. I don't know if all of this is packaged and available > in the archive. Whether you call them tools or scripts, they're outside the archive. Python policy is the wrong place to try to set policy for them. > > and I don't think this is what Barry was referring to. I think he meant > > python commandline programs, which some people may not think of as being > > "applications"? > sure, is "commandline programs" clearer than "Command line scripts"? I think replacing "applications" with "programs" solves the original concern, without this added paragraph. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: favouring Python3 in the Debian policy
On May 07, 2014, at 11:43 PM, Matthias Klose wrote: >thas was "tools outside the archive". Debian has some infrastructure written >in Python. I don't know if all of this is packaged and available in the >archive. I'm personally less concerned about those than packages inside the archive. -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/20140507175617.25ffb...@anarchist.wooz.org
Re: favouring Python3 in the Debian policy
On May 07, 2014, at 02:01 PM, Steve Langasek wrote: >I don't think scripts "outside the archive" are in scope for the python >policy; and I don't think this is what Barry was referring to. I think he >meant python commandline programs, which some people may not think of as >being "applications"? Right. -Barry signature.asc Description: PGP signature
Re: favouring Python3 in the Debian policy
Am 07.05.2014 23:01, schrieb Steve Langasek: > On Wed, May 07, 2014 at 10:15:37PM +0200, Matthias Klose wrote: >> Am 07.05.2014 17:27, schrieb Barry Warsaw: + ++ + Applications should use Python3, and should not be + packaged for Python2 as well. + > >>> Maybe also that system scripts written in Python should be Python 3 and >>> not Python 2. I'd add the clarity just because I'm not sure folks >>> think of such system scripts as "applications". > >> proposing a separate item. > >> Command line scripts, packaging tools, tools used by Debian outside >> the archive, etc. should use Python3, and should not be packaged for >> Python2. > > I don't think scripts "outside the archive" are in scope for the python > policy; thas was "tools outside the archive". Debian has some infrastructure written in Python. I don't know if all of this is packaged and available in the archive. > and I don't think this is what Barry was referring to. I think he meant > python commandline programs, which some people may not think of as being > "applications"? sure, is "commandline programs" clearer than "Command line scripts"? > FWIW, while I think getting the python policy to recommend Python3 is a > good step forward, I think it's more important that we make sure the base > system is leading by example. As described on debian-devel[1], there seem > to be some porting blockers before we can migrate from python to python3 in > the standard install. This is independent. Getting these issues fixed is a dead-end for any other migration of packages to Python3 (well, maybe except for OpenStack). There is no reason for package maintainers to convert to Python3 for other packages. Matthias -- 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/536aa8fc.7030...@debian.org
Re: favouring Python3 in the Debian policy
On 7 May 2014 14:11, Paul Tagliamonte wrote: > If I had more time to blow, I'd likely try a run at something SUDS API > compatible in Python 3. Won't happen any time soon for me, but it's > something I will eternally praise someone over. > > So many people have tried to forward-port the SUDS codebase, > apparently it's *bad*. > This fork looks like it's actively maintained, and has a recent release on PyPI (as suds-jurko): https://bitbucket.org/jurko/suds Thomas
Re: favouring Python3 in the Debian policy
On Wed, May 7, 2014 at 5:01 PM, Steve Langasek wrote: > On Wed, May 07, 2014 at 10:15:37PM +0200, Matthias Klose wrote: >> Am 07.05.2014 17:27, schrieb Barry Warsaw: >> >> + >> >> + >> >> + >> >> +Applications should use Python3, and should not be >> >> +packaged for Python2 as well. >> >> + > >> > Maybe also that system scripts written in Python should be Python 3 and not >> > Python 2. I'd add the clarity just because I'm not sure folks think of >> > such >> > system scripts as "applications". > >> proposing a separate item. > >> >> Command line scripts, packaging tools, tools used by >> Debian outside the archive, etc. should use Python3, and >> should not be packaged for Python2. >> > > I don't think scripts "outside the archive" are in scope for the python > policy; and I don't think this is what Barry was referring to. I think he > meant python commandline programs, which some people may not think of as > being "applications"? > > FWIW, while I think getting the python policy to recommend Python3 is a good > step forward, I think it's more important that we make sure the base system > is leading by example. As described on debian-devel[1], there seem to be > some porting blockers before we can migrate from python to python3 in the > standard install. > > [1] https://lists.debian.org/debian-devel/2014/04/msg00784.html Ugh, suds strikes again. If I had more time to blow, I'd likely try a run at something SUDS API compatible in Python 3. Won't happen any time soon for me, but it's something I will eternally praise someone over. So many people have tried to forward-port the SUDS codebase, apparently it's *bad*. > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developerhttp://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- 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/CAO6P2QR2qfJVofsTMZEarv1UUsV6Ky4HSUb7+X=j4j18bob...@mail.gmail.com
Re: favouring Python3 in the Debian policy
On Wed, May 07, 2014 at 10:15:37PM +0200, Matthias Klose wrote: > Am 07.05.2014 17:27, schrieb Barry Warsaw: > >> + > >> + > >> + > >> +Applications should use Python3, and should not be > >> +packaged for Python2 as well. > >> + > > Maybe also that system scripts written in Python should be Python 3 and not > > Python 2. I'd add the clarity just because I'm not sure folks think of such > > system scripts as "applications". > proposing a separate item. > > Command line scripts, packaging tools, tools used by > Debian outside the archive, etc. should use Python3, and > should not be packaged for Python2. > I don't think scripts "outside the archive" are in scope for the python policy; and I don't think this is what Barry was referring to. I think he meant python commandline programs, which some people may not think of as being "applications"? FWIW, while I think getting the python policy to recommend Python3 is a good step forward, I think it's more important that we make sure the base system is leading by example. As described on debian-devel[1], there seem to be some porting blockers before we can migrate from python to python3 in the standard install. [1] https://lists.debian.org/debian-devel/2014/04/msg00784.html -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: favouring Python3 in the Debian policy
On May 08, 2014, at 06:41 AM, Ben Finney wrote: >Can we converge on a single way to represent the names of these systems >in the document? Currently there seems to be “python3”, “Python3”, >“Python 3” used indiscriminately, without being clear why they would be >spelled differently like that. > >I'd prefer to have: > >* “Python” as the name of the Python system at no specific version; > >* “Python 2” and “Python 3” where the version does matter; And if more detail is necessary, "Python 3.4" or "Python 2.x". >* “python” or “python3” for the name of the runtime interpreter; If an interpreter path is required, "/usr/bin/python3", "/usr/bin/python2", or "/usr/bin/python3.4". >* “Python2” and “Python3” never used. +1 -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/20140507165711.61d8a...@anarchist.wooz.org
Re: favouring Python3 in the Debian policy
Matthias Klose writes: > === modified file 'debian/python-policy.sgml' > --- debian/python-policy.sgml 2013-05-22 02:12:02 + > +++ debian/python-policy.sgml 2014-05-07 14:34:24 + […] > @@ -42,8 +42,7 @@ > > > > - Copyright © 1999, 2001, 2003, 2006, 2009, 2010, 2011, 2012 > - Software in the Public Interest > + Copyright © 1999-2014 Software in the Public Interest > > > This manual is free software; you can redistribute it and/or Minor nit: please use “1999–2014” for a numeric range (U+2013 EN DASH). > @@ -74,6 +73,57 @@ > > > > + > + On the move to Python3 > + > + Debian currently supports two Python stacks, one for Python2 > + and one for Python3. The long term goal for Debian is to > + reduce this to one stack, dropping the Python2 stack at some > + time. Can we converge on a single way to represent the names of these systems in the document? Currently there seems to be “python3”, “Python3”, “Python 3” used indiscriminately, without being clear why they would be spelled differently like that. I'd prefer to have: * “Python” as the name of the Python system at no specific version; * “Python 2” and “Python 3” where the version does matter; * “python” or “python3” for the name of the runtime interpreter; * “Python2” and “Python3” never used. That only applies to the plain text; it doesn't address names in markup, which are not part of the plain text. Some different set of names might make sense, but my larger point is that a policy document should be careful to use terminology consistently. > > The set of currently supported python versions can be found in > - /usr/share/python/debian_defaults. This file is in > + /usr/share/python/debian_defaults, the set of > + currently supported python3 versions can be found > + in /usr/share/python3/debian_defaults. These > + files are in This paragraph is always referring to specific major versions, so “The set of currently supported python versions” also needs to change to “The set of currently supported Python 2 versions”. Thanks for tackling this, Matthias. -- \“I'd take the awe of understanding over the awe of ignorance | `\ any day.” —Douglas Adams | _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/85iophcoeb@benfinney.id.au
Re: favouring Python3 in the Debian policy
Am 07.05.2014 17:27, schrieb Barry Warsaw: >> + >> + >> + >> + Applications should use Python3, and should not be >> + packaged for Python2 as well. >> + > > Maybe also that system scripts written in Python should be Python 3 and not > Python 2. I'd add the clarity just because I'm not sure folks think of such > system scripts as "applications". proposing a separate item. Command line scripts, packaging tools, tools used by Debian outside the archive, etc. should use Python3, and should not be packaged for Python2. >> + >> + >> + >> + Python libraries should be always packaged for Python3 >> + if supported. Python2 libraries should be packaged, if >> + applications dound in the reverse dependencies are not > > s/dound/found/ fixed. -- 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/536a9469.9090...@debian.org
Re: ${python:Depends} to enable dh_python2, ${python3:Depends} - dh_python3?
On May 07, 2014, at 05:49 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2014-05-07]
>> So the fix if they do FTBFS would be to add ${python:Depends} or
>> ${python3:Depends}?
>
>yes. Note that missing ${python:Depends} or ${python3:Depends} in
>Depends in most probably a bug anyway.
I think lintian will complain in that case too.
>The only thing I want to change is to let maintainer decide which
>helper(s) should handle given binary package (the one without public
>modules) in debian/control instead of debian/rules (which I was told is
>not intuitive). Right now both will try to check this package and the
>last one used wins - this leads to questions like "why my /usr/bin/foo
>shebang points to /usr/bin/python3 instead of /usr/bin/python?" or "why
>this package depends on python3?"
Those would be good things to clear up.
>> For example, python-foo-doc or python-foo-common. Case in point: for the
>> wheel package, I wanted the /usr/bin scripts to be shebanged python3. The
>> multi-version build process leaves us with /usr/bin scripts in both the
>> python2 and python3 packages. I throw away the python2 versions and move
>> the python3 versions to the python-wheel-common binary package. That
>> package also contains the manpages of course. It didn't feel right to call
>> that python3-wheel-common but I did want it separate from either the
>> python- or python3- library binary packages.
>
>how about:
>
>* package name starts with python- and contains ${python3:Depends} →
>dh_python3, stop (new)
>* package name starts with python- → dh_python2, stop (current behaviour)
>* package name starts with python3- → dh_python3, stop (current behaviour)
>* package name starts with pypy- → dh_pypy, stop (current behaviour)
>* Depends contains ${python:Depends} → dh_python2 (new)
>* Depends contains ${python3:Depends} → dh_python3 (new)
>* Depends contains ${pypy:Depends} → dh_pypy (new)
>* ignore other packages (new)
LGTM, but I guess we'll see how it works out in practice. :)
-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/20140507125351.62358...@anarchist.wooz.org
Re: ${python:Depends} to enable dh_python2, ${python3:Depends} - dh_python3?
[Barry Warsaw, 2014-05-07]
> So the fix if they do FTBFS would be to add ${python:Depends} or
> ${python3:Depends}?
yes. Note that missing ${python:Depends} or ${python3:Depends} in
Depends in most probably a bug anyway.
> There's another weird corner case I guess, which is, that related binary
> packages that may contain some data but not necessarily the actual /usr/lib
> code could start with python-.
dh_python* scans such packages, doesn't find any interesting data and
ignores it.
The only thing I want to change is to let maintainer decide which
helper(s) should handle given binary package (the one without public
modules) in debian/control instead of debian/rules (which I was told is
not intuitive). Right now both will try to check this package and the
last one used wins - this leads to questions like "why my /usr/bin/foo
shebang points to /usr/bin/python3 instead of /usr/bin/python?" or "why
this package depends on python3?"
> For example, python-foo-doc or python-foo-common. Case in point: for the
> wheel package, I wanted the /usr/bin scripts to be shebanged python3. The
> multi-version build process leaves us with /usr/bin scripts in both the
> python2 and python3 packages. I throw away the python2 versions and move the
> python3 versions to the python-wheel-common binary package. That package also
> contains the manpages of course. It didn't feel right to call that
> python3-wheel-common but I did want it separate from either the python- or
> python3- library binary packages.
how about:
* package name starts with python- and contains ${python3:Depends} →
dh_python3, stop (new)
* package name starts with python- → dh_python2, stop (current behaviour)
* package name starts with python3- → dh_python3, stop (current behaviour)
* package name starts with pypy- → dh_pypy, stop (current behaviour)
* Depends contains ${python:Depends} → dh_python2 (new)
* Depends contains ${python3:Depends} → dh_python3 (new)
* Depends contains ${pypy:Depends} → dh_pypy (new)
* ignore other packages (new)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20140507154905.ge19...@sts0.p1otr.com
Re: Bug #732703 and fixing ensurepip/pyvenv
On May 7, 2014, at 11:35 AM, Barry Warsaw wrote: > The stuff vendorized inside there don't have to have the > dist-info directories, so perhaps they don't need to be wheeled at all, but > they *do* have to be vendorized because of technicalities in the way pip works > within a virtual environment. To be specific, they cannot appear as installed to a ``pip list`` command, where they are imported from doesn’t particular matter. Acceptable: 1. Putting them unpacked in pip/_vendor/ and modify the imports to import things from pip._vendor (aka what pip normally does) 2. Putting them unpacked in pip/_vendor/ (or anywhere really) *without* dist-info/egg-info and modifying sys.path to add that path. 3. Putting them packed in a zip file (whl or plain zip) in pip/_vendor (or anywhere really) and modifying sys.path to add those zips. Unacceptable: 4. Installing them directly into the virtual environment 5. Putting them unpacked in pip/_vendor/ (or anywhere really) *with* dist-info/egg-info and modifying sys.path to add that path. Basically if pkg_resources can find a dist-info/egg-info for it, then it'll see it installed and it'll be available for ``pip uninstall`` (explicitly or implicitly through an upgrade/downgrade). Also to be explicit, I've never actually tested what pip will do if there are *two* copies of requests (for example), one installed into site-packages with a dist-info/egg-info and one being just the ``requests`` directory that had been added into sys.path (basically options 2 and 3). I *think* it will work but that should be tested. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bug #732703 and fixing ensurepip/pyvenv
On May 07, 2014, at 12:21 PM, Matthias Klose wrote: >pip is a specical case here, because we want to mimic the wheel packages which >come with python upstream. these can't be shipped in the debian python source >package, but they are needed to make the pyvenv command work. so we have to >construct these out of the debian supplied packages, and best in a form that >these cannot be broken by updates in the venv, i.e. re-vendorized. Donald in IRC confirmed that only the pip and setuptools wheels inside of ensurepip need to have the dist-info directories. I think the easiest way to create those are by creating their wheels at python-pip and python-setuptools package build times. The stuff vendorized inside there don't have to have the dist-info directories, so perhaps they don't need to be wheeled at all, but they *do* have to be vendorized because of technicalities in the way pip works within a virtual environment. I just thought that wheeling those vendorized libraries were a clever and easy way to make that vendorizing work, but maybe it's unnecessary. I'm definitely not suggesting that every Python library in the archive also grow -wheel packages! -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/20140507113544.1578c...@anarchist.wooz.org
Re: favouring Python3 in the Debian policy
On Wednesday, May 07, 2014 11:27:20 Barry Warsaw wrote: > Should we also update Appendix B to promote --buildsystem=pybuild or at > least reference it? It's a reasonably safe bet that almost anything needs update. 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/1765802.AhhHbdc04b@scott-latitude-e6320
Re: favouring Python3 in the Debian policy
On May 07, 2014, at 04:45 PM, Matthias Klose wrote: >Attached is a proposed change to the Debian Python policy to focus on Python3 >within the distribution. The intent is to document and start a large journey >towards one Python stack in Debian. This is unlikely to happen for jessie+1, >but we should state the plan now so that it doesn't come later as a surprise. === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml 2013-05-22 02:12:02 + +++ debian/python-policy.sgml 2014-05-07 14:34:24 + > @@ -74,6 +73,57 @@ > > > > + > + On the move to Python3 > + > + Debian currently supports two Python stacks, one for Python2 > + and one for Python3. The long term goal for Debian is to > + reduce this to one stack, dropping the Python2 stack at some > + time. > + http://legacy.python.org/dev/peps/pep-0404/"; > + name="PEP 404"> states that no more major Python2 releases > + are planned, although the last released major version 2.7 > + will see some extended support, documented in > + http://legacy.python.org/dev/peps/pep-0466/"; > + name="PEP 466">. > + > + > + Packages in Debian should use Python3 if Python3 is > + supported. New packages should use Python3 from the initial > + upload, new upstream versions for existing packages should > + use Python3 if the new upstream version supports it. > + > + > + > + > + > + Applications should use Python3, and should not be > + packaged for Python2 as well. > + Maybe also that system scripts written in Python should be Python 3 and not Python 2. I'd add the clarity just because I'm not sure folks think of such system scripts as "applications". > + > + > + > + Python libraries should be always packaged for Python3 > + if supported. Python2 libraries should be packaged, if > + applications dound in the reverse dependencies are not s/dound/found/ > + yet supported by Python3. > + > + > + > + > + Existing Python2 libraries should not be dropped before > + the last reverse dependency is removed. > + > + > + > + > + > + Python3 (3.1) was released in June 2009, and is available in > + the Debian 6.0 (squeeze) release (3.1), and in the Debian 7 > + (wheezy) release (3.2). > + > + > + > >Python Packaging > > @@ -117,7 +167,10 @@ > > > The set of currently supported python versions can be found in > - /usr/share/python/debian_defaults. This file is in > + /usr/share/python/debian_defaults, the set of > + currently supported python3 versions can be found > + in /usr/share/python3/debian_defaults. These > + files are in > Python ConfigParser format and defines four variables in its > DEFAULT section: default-version which is the current default > Python runtime, supported-versions which is the set of runtimes Should we also update Appendix B to promote --buildsystem=pybuild or at least reference it? -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/20140507112720.1850c...@anarchist.wooz.org
Re: Bug #702005: Where can i get more attention on this?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anyone? Matthias, perhaps?
Greetings,
On 06/05/14 20:05, Luis Alejandro Martínez Faneyth wrote:
> Hi everyone,
>
> I'm a little worried about bug #702005 and the lack of attention
> it's getting.
>
> This bug is marked as resolved, and indeed it has been resolved
> for jessie and sid, but not for wheezy. This bug breaks Python 2.7.
> Every person that tries to upgrade python2.7 and python2.7-minimal
> from version 2.7.3-6 to 2.7.3-6+deb7u2, is affected by this bug.
> We're talking about everybody who installed Wheezy 7.{0,1,2,3,4}
> and tries to upgrade today.
>
> This is affecting also every debian derivative based on stable, and
> is worth mentioning:
>
> XBian: http://forum.xbian.org/post-21595.html#pid21595 Aptosid:
> http://www.aptosid.com/index.php?name=PNphpBB2&file=viewtopic&t=2556
>
>
Canaima
> (spanish):
> http://listas.canaima.softwarelibre.gob.ve/pipermail/soporte/2014-April/009621.html
>
> Please, can someone upload the fix to wheezy also?
>
> Or, how can i help?
>
> Thanks,
>
> -- Luis Alejandro Martínez Faneyth Blog:
> http://huntingbears.com.ve Github: http://github.com/LuisAlejandro
> Twitter: http://twitter.com/LuisAlejandro
>
> CODE IS POETRY
- --
Luis Alejandro Martínez Faneyth
Blog: http://huntingbears.com.ve
Github: http://github.com/LuisAlejandro
Twitter: http://twitter.com/LuisAlejandro
CODE IS POETRY
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBAgAGBQJTak18AAoJEPYUWpXnjaouJw4P/2QFz6oMenAbHN9m5CeQC4UQ
y2v4TnyYn7xnnT+BnZwu5BwgbOSvIocIiS+YSCS8hEUv2+XY4aVNG+jzWvd/O5Vd
RN8IqcBsJ/o+vpK7mg3xaiTEP0fIGh+7M+A14jq4//lxYIPuYVkK3fERmD71/JrB
Z+DI77FW51gcTIN//4X628/yjIPWsAKaXIoYMgrtiN3TKYQPl3y4CYLhevLug1Iz
8Ue4VwmAL09/eJFm6gXdomhIaNnC8TAUPRFkTkU/PCuNXZqF6jkoRyf+55NRJjuV
D5IGfimqkIKkdTVqfZaoVleKgvtmB6wZxEjXu7uryVQbnplE0LqmsJfQAb0rkjHE
6CHmR9O9AdOpBatS4+n7Q2Do21avSeDPfz1XtlINFf4PrQHWjQHf1DSntjAnl4Ja
a+g+kqkwm7SAJt8pPAebfri9GbBtOZgpGiCuKKUUUW1tKhpkoy6EUYkZOk7fFER3
F74dpuk/le6tF8MPqYzIcDtQpKlzN23non3D3/2aXqloZw9HUB1uTgFd91yacNUH
ayKiiD/y+DYr0oe2Fo55wwWsueQDwTa2ifVA5INc80lOJpECoUMB/U7L5kTRRQhj
hAfxg+1Mnx8C04tq0p4h8G5hfSH3dEA4adRTDVHSA3C4lUW4LADe2Wtq8lXU2xRS
HmFiNSKJj7yaTf7SmCZr
=DfmG
-END PGP SIGNATURE-
--
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/blu436-smtp16067a91f98d08cb7e69fa08b...@phx.gbl
favouring Python3 in the Debian policy
Attached is a proposed change to the Debian Python policy to focus on Python3 within the distribution. The intent is to document and start a large journey towards one Python stack in Debian. This is unlikely to happen for jessie+1, but we should state the plan now so that it doesn't come later as a surprise. Matthias === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml 2013-05-22 02:12:02 + +++ debian/python-policy.sgml 2014-05-07 14:34:24 + @@ -32,7 +32,7 @@ Scott Kitterman sc...@kitterman.com - version 0.9.4.2 + version 0.9.5 This document describes the packaging of Python within the @@ -42,8 +42,7 @@ - Copyright © 1999, 2001, 2003, 2006, 2009, 2010, 2011, 2012 - Software in the Public Interest + Copyright © 1999-2014 Software in the Public Interest This manual is free software; you can redistribute it and/or @@ -74,6 +73,57 @@ + + On the move to Python3 + + Debian currently supports two Python stacks, one for Python2 + and one for Python3. The long term goal for Debian is to + reduce this to one stack, dropping the Python2 stack at some + time. + http://legacy.python.org/dev/peps/pep-0404/"; + name="PEP 404"> states that no more major Python2 releases + are planned, although the last released major version 2.7 + will see some extended support, documented in + http://legacy.python.org/dev/peps/pep-0466/"; + name="PEP 466">. + + + Packages in Debian should use Python3 if Python3 is + supported. New packages should use Python3 from the initial + upload, new upstream versions for existing packages should + use Python3 if the new upstream version supports it. + + + + + + Applications should use Python3, and should not be + packaged for Python2 as well. + + + + + Python libraries should be always packaged for Python3 + if supported. Python2 libraries should be packaged, if + applications dound in the reverse dependencies are not + yet supported by Python3. + + + + + Existing Python2 libraries should not be dropped before + the last reverse dependency is removed. + + + + + + Python3 (3.1) was released in June 2009, and is available in + the Debian 6.0 (squeeze) release (3.1), and in the Debian 7 + (wheezy) release (3.2). + + + Python Packaging @@ -117,7 +167,10 @@ The set of currently supported python versions can be found in - /usr/share/python/debian_defaults. This file is in + /usr/share/python/debian_defaults, the set of + currently supported python3 versions can be found + in /usr/share/python3/debian_defaults. These + files are in Python ConfigParser format and defines four variables in its DEFAULT section: default-version which is the current default Python runtime, supported-versions which is the set of runtimes
Re: ${python:Depends} to enable dh_python2, ${python3:Depends} - dh_python3?
On May 07, 2014, at 12:22 PM, Matthias Klose wrote:
>Am 07.05.2014 12:17, schrieb Piotr Ożarowski:
>> dh_python2 ignores python3-* packages, dh_python3 ignores python-*
>> packages, but in all other packages both of them will try to handle .py
>> files. To avoid possible unnecessary dependencies or shebang rewrites,
>> debhelper's -N (--no-package) or -p (--package) options should be used.
>>
>> Should I change dh_python* behaviour to ignore all binary packages that
>> do not have appropriate ${python:Depends} template in Depends?
>
>how many packages will fail to build, or will produce non working packages
>with this change?
So the fix if they do FTBFS would be to add ${python:Depends} or
${python3:Depends}?
There's another weird corner case I guess, which is, that related binary
packages that may contain some data but not necessarily the actual /usr/lib
code could start with python-.
For example, python-foo-doc or python-foo-common. Case in point: for the
wheel package, I wanted the /usr/bin scripts to be shebanged python3. The
multi-version build process leaves us with /usr/bin scripts in both the
python2 and python3 packages. I throw away the python2 versions and move the
python3 versions to the python-wheel-common binary package. That package also
contains the manpages of course. It didn't feel right to call that
python3-wheel-common but I did want it separate from either the python- or
python3- library binary packages.
-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/20140507101119.1d87f...@anarchist.wooz.org
Re: Bug #732703 and fixing ensurepip/pyvenv
[Matthias Klose, 2014-05-07]
> Am 07.05.2014 10:16, schrieb Piotr Ożarowski:
> > [Barry Warsaw, 2014-05-07]
> >> Generating the wheels during package build is pretty easy I think. You
> >> just
> >> B-D on python*-wheel (which just got approved from NEW) and then if the
> >> package uses setuptools, you just add something like:
> >>
> >> python3 setup.py bdist_wheel -d \
> >> debian/python-foo-wheels/usr/share/python-wheels
> >> dh_installdirs -ppython-foo-wheels usr/share
> >>
> >> after you've added the python-foo-wheels binary package. (Exact package
> >> names, directory paths, etc. TBD, but these are what I've picked for my
> >> experiments.)
> >
> > this will double the size of python{,3}-* packages in our archive and
> > force us to update thousands of source packages.
> >
> > What do wheels have that our binary packages do not have? Aren't they
> > just a zipped .py files? I'm probably missing something, but why can't
> > we zip `dpkg -L python-foo | grep /dist-packages`'s output at runtime
> > (when someone python3 -m ensirepips something)?
>
> as long as wheels are limited to zip files and can't reference files on the
> file
> system, these should not be included into the distro. compared to eggs this
> is
> a regression.
>
> pip is a specical case here, because we want to mimic the wheel packages which
> come with python upstream. these can't be shipped in the debian python source
> package, but they are needed to make the pyvenv command work. so we have to
> construct these out of the debian supplied packages, and best in a form that
> these cannot be broken by updates in the venv, i.e. re-vendorized.
so "foo" in "python-foo-wheels" is "pip" and "setuptools" only?
OK then, I had a bad feeling it's another "lets reinvent the wheel!"
thing.
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20140507104125.gd19...@sts0.p1otr.com
Re: ${python:Depends} to enable dh_python2, ${python3:Depends} - dh_python3?
[Matthias Klose, 2014-05-07]
> Am 07.05.2014 12:17, schrieb Piotr Ożarowski:
> > Should I change dh_python* behaviour to ignore all binary packages that
> > do not have appropriate ${python:Depends} template in Depends?
>
> how many packages will fail to build, or will produce non working packages
> with
> this change?
I don't have numbers... yet. I want to do this only for packages with names
not starting with python- or python3- (i.e. for packages with private
modules and/or scripts only so such packages shouldn't FTBFS; worst
scenario is they will not have proper .pyc files handling at runtime)
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20140507103031.gc19...@sts0.p1otr.com
Re: ${python:Depends} to enable dh_python2, ${python3:Depends} - dh_python3?
Am 07.05.2014 12:17, schrieb Piotr Ożarowski:
> dh_python2 ignores python3-* packages, dh_python3 ignores python-*
> packages, but in all other packages both of them will try to handle .py
> files. To avoid possible unnecessary dependencies or shebang rewrites,
> debhelper's -N (--no-package) or -p (--package) options should be used.
>
> Should I change dh_python* behaviour to ignore all binary packages that
> do not have appropriate ${python:Depends} template in Depends?
how many packages will fail to build, or will produce non working packages with
this change?
--
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/536a0973.1020...@debian.org
Re: Bug #732703 and fixing ensurepip/pyvenv
Am 07.05.2014 10:16, schrieb Piotr Ożarowski:
> [Barry Warsaw, 2014-05-07]
>> Generating the wheels during package build is pretty easy I think. You just
>> B-D on python*-wheel (which just got approved from NEW) and then if the
>> package uses setuptools, you just add something like:
>>
>> python3 setup.py bdist_wheel -d \
>> debian/python-foo-wheels/usr/share/python-wheels
>> dh_installdirs -ppython-foo-wheels usr/share
>>
>> after you've added the python-foo-wheels binary package. (Exact package
>> names, directory paths, etc. TBD, but these are what I've picked for my
>> experiments.)
>
> this will double the size of python{,3}-* packages in our archive and
> force us to update thousands of source packages.
>
> What do wheels have that our binary packages do not have? Aren't they
> just a zipped .py files? I'm probably missing something, but why can't
> we zip `dpkg -L python-foo | grep /dist-packages`'s output at runtime
> (when someone python3 -m ensirepips something)?
as long as wheels are limited to zip files and can't reference files on the file
system, these should not be included into the distro. compared to eggs this is
a regression.
pip is a specical case here, because we want to mimic the wheel packages which
come with python upstream. these can't be shipped in the debian python source
package, but they are needed to make the pyvenv command work. so we have to
construct these out of the debian supplied packages, and best in a form that
these cannot be broken by updates in the venv, i.e. re-vendorized.
Matthias
--
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/536a0912.4020...@debian.org
${python:Depends} to enable dh_python2, ${python3:Depends} - dh_python3?
dh_python2 ignores python3-* packages, dh_python3 ignores python-*
packages, but in all other packages both of them will try to handle .py
files. To avoid possible unnecessary dependencies or shebang rewrites,
debhelper's -N (--no-package) or -p (--package) options should be used.
Should I change dh_python* behaviour to ignore all binary packages that
do not have appropriate ${python:Depends} template in Depends?
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20140507101723.gb19...@sts0.p1otr.com
Re: Bug #732703 and fixing ensurepip/pyvenv
[Barry Warsaw, 2014-05-07]
> Generating the wheels during package build is pretty easy I think. You just
> B-D on python*-wheel (which just got approved from NEW) and then if the
> package uses setuptools, you just add something like:
>
> python3 setup.py bdist_wheel -d \
> debian/python-foo-wheels/usr/share/python-wheels
> dh_installdirs -ppython-foo-wheels usr/share
>
> after you've added the python-foo-wheels binary package. (Exact package
> names, directory paths, etc. TBD, but these are what I've picked for my
> experiments.)
this will double the size of python{,3}-* packages in our archive and
force us to update thousands of source packages.
What do wheels have that our binary packages do not have? Aren't they
just a zipped .py files? I'm probably missing something, but why can't
we zip `dpkg -L python-foo | grep /dist-packages`'s output at runtime
(when someone python3 -m ensirepips something)?
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
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/20140507081613.ga19...@sts0.p1otr.com
