Re: Embedded six.py in many packages: can someone add a lintian check?
On 05/28/2014 10:02 PM, Barry Warsaw wrote: > Unfortunately, it's not just six that gets vendorized. I'd be in favor of a > lintian check if it could be generalized to warn against all vendorizing. A > warning specifically about six is helpful but limited. Hi Barry, How would you implement the generalization then? Thomas -- 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/5386f410.1060...@debian.org
Re: Join the Team
Hi Vincent, I've commited my changes to the SVN repo. It should be good now. I've also released and tagged the new version. Regards, Hugo -- Hugo Lefeuvre (hugo6390)|www.hugo6390.org 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E signature.asc Description: Digital signature
Re: Embedded six.py in many packages: can someone add a lintian check?
On May 29, 2014, at 04:47 PM, Thomas Goirand wrote: >On 05/28/2014 10:02 PM, Barry Warsaw wrote: >> Unfortunately, it's not just six that gets vendorized. I'd be in favor of a >> lintian check if it could be generalized to warn against all vendorizing. A >> warning specifically about six is helpful but limited. > >How would you implement the generalization then? Yeah, that's the trick; I'm not sure. The best I could come up with was an a priori list of known common vendorizations. It would be imperfect for sure, and maybe a pain to keep up-to-date, but I can't think of anything better given what we have to work with today. One of the things I want to add to my mythical PEP are at least declarations of vendored packages. 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/20140529105352.49bcf...@anarchist.wooz.org
Re: Embedded six.py in many packages: can someone add a lintian check?
On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote: > One of the things I want to add to my mythical PEP are at least declarations > of vendored packages. What tool do people use to do vendorising? Maybe that could be patched to include a file containing info about which projects were vendorised. -- 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/caktje6hanarhjo+ltl6tqsccnbmagtq79t89nxyyvdgwuak...@mail.gmail.com
Re: Embedded six.py in many packages: can someone add a lintian check?
On May 29, 2014, at 10:58 PM, Paul Wise wrote: >On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote: > >> One of the things I want to add to my mythical PEP are at least declarations >> of vendored packages. > >What tool do people use to do vendorising? AFAICT it's mostly `$foreignvcs pull; cp -a; $myvcs commit`. So not very helpful. ;) -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/20140529111335.40b9e...@anarchist.wooz.org
Re: Embedded six.py in many packages: can someone add a lintian check?
On Thu, May 29, 2014 at 11:13 PM, Barry Warsaw wrote: > On May 29, 2014, at 10:58 PM, Paul Wise wrote: > >>On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote: >> >>> One of the things I want to add to my mythical PEP are at least declarations >>> of vendored packages. >> >>What tool do people use to do vendorising? > > AFAICT it's mostly `$foreignvcs pull; cp -a; $myvcs commit`. > > So not very helpful. ;) What about encouraging often-vendorised projects to include a comment like "Project: foo" in their __init__.py? Then lintian could detect if there are multiple projects in one tarball. -- 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/caktje6hfj9xvfwclsdsd_wcqnhaq596fmgbfjvkmmgiy8by...@mail.gmail.com
Re: Embedded six.py in many packages: can someone add a lintian check?
* Barry Warsaw , 2014-05-29, 10:53: Unfortunately, it's not just six that gets vendorized. I'd be in favor of a lintian check if it could be generalized to warn against all vendorizing. A warning specifically about six is helpful but limited. How would you implement the generalization then? Yeah, that's the trick; I'm not sure. The best I could come up with was an a priori list of known common vendorizations. So something like this: https://bitbucket.org/jwilk/lintian4python/src/default/vendors/debian/python/data/python2-embedded-code-copies ? -- Jakub Wilk -- 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/20140529161246.ga4...@jwilk.net
python-Pandocfilters
Hello, I have prepared a package for python-pandocfilters. AFAIT, it should correspond to the python packaging guidelines and it builds nicely with Debhelper. BTW, thanks to the developers and to those who documented the process, great job! It is Lintian-clean, but I would love to have someone looking over it, because this is my first Python-related package. I think it would make also sense to include it in the debian-python team repositories, if you wish. If so, please add me on alioth (moomoc-guest), and I'll create a git repository there. Thanks Sebastian -- Web: http://www.crustulus.de | Blog: http://www.crustulus.de/cgi-bin/blog.cgi?de-0 Freies Latein-Deutsch-Wörterbuch: http://www.crustulus.de/freedict.de.html FreeDict: Free multilingual dictionary databases - http://www.freedict.org signature.asc Description: Digital signature
Re: Python3.4 is default python3
On May 28, 2014, at 12:49 AM, Scott Kitterman wrote: >Is anyone aware of anything that would prevent dropping python3.3 from >supported versions as soon as this transition is done? Nope, let's do it. (I'll see what I can do about helping out with #746709.) -Barry signature.asc Description: PGP signature
Proposed changes to python-virtualenv
I'm looking again at updating tox to the latest upstream 1.7.1. Along the way, I'd like to make /usr/bin/tox a Python 3 script. This requires that virtualenv be importable, e.g. `$python -m virtualenv`. It is today in Python 2 since /usr/bin/virtualenv is a Python 2 script and we only build it for one version of Python. I want to change that too, so that at least we build the virtualenv modules for both Python 2 and 3. I'd like to switch /usr/bin/virtualenv to be Python 3 as well, and I'd like to tackle the vendorizing issue similar to how we fixed it with ensurepip, since we have all the wheels we need now. This means however that I need to rejigger the binary packages in the python-virtualenv source package. Right now, python-virtualenv contains both the modules and /usr/bin/virtualenv. I need to at least add a python3-virtualenv package to contain the Python 3 modules. But it doesn't make sense to have a /usr/bin/virtualenv with both a Python 2 and Python 3 shebang line, and thus it doesn't make sense to put Python 3 /usr/bin/virtualenv in the python-virtualenv binary package. However, I still want to make it obvious and easy which package someone needs to install to get the command line script. My thinking is that I would add a `virtualenv` binary package which would contain just the /usr/bin script (with a Python3 shebang) and any other common files as makes sense (e.g. the manpage). `virtualenv` would Replaces/Breaks `python-virtualenv` and Depends on python3-virtualenv. I thought about using a python-virtualenv-common for that but since this will be the most likely installed package for end users, I thought `apt-get install virtualenv` looked nicer. Thoughts? -Barry signature.asc Description: PGP signature
Re: Proposed changes to python-virtualenv
On May 29, 2014 7:54:53 PM EDT, Barry Warsaw wrote: >I'm looking again at updating tox to the latest upstream 1.7.1. Along >the >way, I'd like to make /usr/bin/tox a Python 3 script. > >This requires that virtualenv be importable, e.g. `$python -m >virtualenv`. It >is today in Python 2 since /usr/bin/virtualenv is a Python 2 script and >we >only build it for one version of Python. I want to change that too, so >that >at least we build the virtualenv modules for both Python 2 and 3. I'd >like to >switch /usr/bin/virtualenv to be Python 3 as well, and I'd like to >tackle the >vendorizing issue similar to how we fixed it with ensurepip, since we >have all >the wheels we need now. ... >Thoughts? >-Barry I'd rather remove the wheels we have and give up on ensurepip than start down this slippery slope. Wheels are an ugly solution for us to work around upstream doing things that can most charitably be described as fixing problems we don't have. No more. 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/fe6d444f-cbb7-44b1-9a6e-c7ed1d905...@email.android.com
Re: Proposed changes to python-virtualenv
On May 29, 2014, at 8:15 PM, Scott Kitterman wrote: > On May 29, 2014 7:54:53 PM EDT, Barry Warsaw wrote: >> I'm looking again at updating tox to the latest upstream 1.7.1. Along >> the >> way, I'd like to make /usr/bin/tox a Python 3 script. >> >> This requires that virtualenv be importable, e.g. `$python -m >> virtualenv`. It >> is today in Python 2 since /usr/bin/virtualenv is a Python 2 script and >> we >> only build it for one version of Python. I want to change that too, so >> that >> at least we build the virtualenv modules for both Python 2 and 3. I'd >> like to >> switch /usr/bin/virtualenv to be Python 3 as well, and I'd like to >> tackle the >> vendorizing issue similar to how we fixed it with ensurepip, since we >> have all >> the wheels we need now. > ... >> Thoughts? >> -Barry > > I'd rather remove the wheels we have and give up on ensurepip than start down > this slippery slope. > > Wheels are an ugly solution for us to work around upstream doing things that > can most charitably be described as fixing problems we don't have. No more. > > Scott K Eh, it’s not true that users of Debian do not have the problems that ensurepip solves. Perhaps *you* don’t personally have them but anyone whose ever needed to install a set of Python packages that Debian either doesn’t package, or packages the wrong version of them have the problems that virtualenv/venv solves and virtualenv/venv without pip is practically worthless. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Proposed changes to python-virtualenv
On May 29, 2014, at 7:54 PM, Barry Warsaw wrote: > I'm looking again at updating tox to the latest upstream 1.7.1. Along the > way, I'd like to make /usr/bin/tox a Python 3 script. > > This requires that virtualenv be importable, e.g. `$python -m virtualenv`. It > is today in Python 2 since /usr/bin/virtualenv is a Python 2 script and we > only build it for one version of Python. I want to change that too, so that > at least we build the virtualenv modules for both Python 2 and 3. I'd like to > switch /usr/bin/virtualenv to be Python 3 as well, and I'd like to tackle the > vendorizing issue similar to how we fixed it with ensurepip, since we have all > the wheels we need now. > > This means however that I need to rejigger the binary packages in the > python-virtualenv source package. Right now, python-virtualenv contains both > the modules and /usr/bin/virtualenv. I need to at least add a > python3-virtualenv package to contain the Python 3 modules. But it doesn't > make sense to have a /usr/bin/virtualenv with both a Python 2 and Python 3 > shebang line, and thus it doesn't make sense to put Python 3 > /usr/bin/virtualenv in the python-virtualenv binary package. However, I still > want to make it obvious and easy which package someone needs to install to get > the command line script. > > My thinking is that I would add a `virtualenv` binary package which would > contain just the /usr/bin script (with a Python3 shebang) and any other common > files as makes sense (e.g. the manpage). `virtualenv` would Replaces/Breaks > `python-virtualenv` and Depends on python3-virtualenv. > > I thought about using a python-virtualenv-common for that but since this will > be the most likely installed package for end users, I thought `apt-get install > virtualenv` looked nicer. > > Thoughts? > -Barry Does anything other than tox depend on virtualenv? Unless something python 2.x depends on virtualenv the only real benefit to having virtualenv installed in both 2.x and 3.x is what the default interpreter is whenever you create a virtual environment. IOW virtualenv is perfectly capable of creating virtual environments in interpreters other than the one it's installed in. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Proposed changes to python-virtualenv
On May 29, 2014, at 08:15 PM, Scott Kitterman wrote: >I'd rather remove the wheels we have and give up on ensurepip than start down >this slippery slope. That means we give up on pyvenv, and given that virtualenv will eventually be a wrapper around pyvenv, that means we give up on virtual environments. Thus we eventually give up on tools like tox to test code in multiple versions of Python, and we give up on developers being able to work on code in isolated environments, or with packages that aren't in Debian, or have different versions than exist in Debian. Given how prevalent and important virtual environments are for Python development, it means we are essentially turning our back on all Python developers. >Wheels are an ugly solution for us to work around upstream doing things that >can most charitably be described as fixing problems we don't have. No more. Wheels are a solution to a problem that is *explicitly* Debian, given the policy and DFSG violations vendorizing entails. Upstream doesn't have the same concern. -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/20140529205313.1fe09...@anarchist.wooz.org
Re: Proposed changes to python-virtualenv
On May 29, 2014, at 08:30 PM, Donald Stufft wrote: >Does anything other than tox depend on virtualenv? Unless something python >2.x depends on virtualenv the only real benefit to having virtualenv >installed in both 2.x and 3.x is what the default interpreter is whenever you >create a virtual environment. IOW virtualenv is perfectly capable of creating >virtual environments in interpreters other than the one it's installed in. Yep, which is why I want to change the shebang to /usr/bin/python3. reverse-depends python-virtualenv Reverse-Depends === * dh-virtualenv * pbundler * python-tox * virtualenvwrapper (that's on Ubuntu, but it should be close if not identical) I don't know yet whether any of those packages actually try to import virtualenv or whether they just use the command line. I guess if nothing else does import it, then we don't need the Python 2 version of the library and we can just switch the python-virtualenv package to install only the Python 3 bits. -Barry signature.asc Description: PGP signature
Re: Proposed changes to python-virtualenv
On May 29, 2014 8:27:07 PM EDT, Donald Stufft wrote: > >On May 29, 2014, at 8:15 PM, Scott Kitterman >wrote: > >> On May 29, 2014 7:54:53 PM EDT, Barry Warsaw >wrote: >>> I'm looking again at updating tox to the latest upstream 1.7.1. >Along >>> the >>> way, I'd like to make /usr/bin/tox a Python 3 script. >>> >>> This requires that virtualenv be importable, e.g. `$python -m >>> virtualenv`. It >>> is today in Python 2 since /usr/bin/virtualenv is a Python 2 script >and >>> we >>> only build it for one version of Python. I want to change that too, >so >>> that >>> at least we build the virtualenv modules for both Python 2 and 3. >I'd >>> like to >>> switch /usr/bin/virtualenv to be Python 3 as well, and I'd like to >>> tackle the >>> vendorizing issue similar to how we fixed it with ensurepip, since >we >>> have all >>> the wheels we need now. >> ... >>> Thoughts? >>> -Barry >> >> I'd rather remove the wheels we have and give up on ensurepip than >start down this slippery slope. >> >> Wheels are an ugly solution for us to work around upstream doing >things that can most charitably be described as fixing problems we >don't have. No more. >> >> Scott K > >Eh, it’s not true that users of Debian do not have the problems that >ensurepip >solves. Perhaps *you* don’t personally have them but anyone whose ever >needed >to install a set of Python packages that Debian either doesn’t package, >or >packages the wrong version of them have the problems that >virtualenv/venv >solves and virtualenv/venv without pip is practically worthless. I was referring to wheels. It's my understanding that they are primarily for platforms without package management. 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/21650414-59a7-43aa-8273-f7eb497d5...@email.android.com
Re: Proposed changes to python-virtualenv
On May 29, 2014, at 08:59 PM, Scott Kitterman wrote: >I was referring to wheels. It's my understanding that they are primarily for >platforms without package management. We use them in the pyvenv solution (and soon in the virtualenv de-policy-violating solution) because they're the best way (IMHO) of solving the technical implementation details with devendorizing pip and virtualenv and their recursive dependencies. That's why for example, we *don't* use wheels to devendorize requests or urllib3 when used as a module, but we do use them in pip within the virtual environment. -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/20140529210353.3c01e...@anarchist.wooz.org
Dependency of virtual environments on Python wheel (was: Proposed changes to python-virtualenv)
Barry Warsaw writes: > On May 29, 2014, at 08:15 PM, Scott Kitterman wrote: > > >I'd rather [Debian] remove the wheels we have and give up on > >ensurepip than start down this slippery slope. > > That means we give up on pyvenv, and given that virtualenv will > eventually be a wrapper around pyvenv, that means we give up on > virtual environments. Could you expand on that? What is it about pyvenv, or wheel, or both, that leads from Debian removing wheel packages to Debian “giving up on pyvenv”? Or, if you prefer, what is it about pyvenv that makes it infeasible to do without wheel packages? > Wheels are a solution to a problem that is *explicitly* Debian, given > the policy and DFSG violations vendorizing entails. Upstream doesn't > have the same concern. (I think by “to vendorize” you mean “to bundle”. Why the neologism “vendorize”, what is the distinction?) What do wheels do which address Debian in particular? Why is it that Debian can't ignore wheels as superfluous? -- \ “It is well to remember that the entire universe, with one | `\ trifling exception, is composed of others.” —John Andrew Holmes | _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/85iooo2hez.fsf...@benfinney.id.au
Re: Dependency of virtual environments on Python wheel (was: Proposed changes to python-virtualenv)
On May 29, 2014, at 9:18 PM, Ben Finney wrote: > Barry Warsaw writes: > >> On May 29, 2014, at 08:15 PM, Scott Kitterman wrote: >> >>> I'd rather [Debian] remove the wheels we have and give up on >>> ensurepip than start down this slippery slope. >> >> That means we give up on pyvenv, and given that virtualenv will >> eventually be a wrapper around pyvenv, that means we give up on >> virtual environments. > > Could you expand on that? What is it about pyvenv, or wheel, or both, > that leads from Debian removing wheel packages to Debian “giving up on > pyvenv”? > > Or, if you prefer, what is it about pyvenv that makes it infeasible to > do without wheel packages? pyvenv doesn't strictly need Wheels themselves, but it needs something that is capable of interrogating Python to ask it where it should install the packages as well as which is capable of understanding virtual environments at all. Historically virtualenv has done this by embedding sdists, manually unpacking them, and then executing setup.py. With the most recent version of virtualenv, and with pyenv (which uses ensurepip) this has been switched to wheels since they are really just fancy zip files which means that Python is able to import them directly. This allows pyenv (again via ensurepip) and virtualenv to use pip to install both itself and setuptools instead of directly executing setup.py. This has made the bootstrapping of setuptools/pip into these virtual environments cleaner, faster, and simpler. Strictly speaking as well, pyvenv itself doesn't require ensurepip (where the wheels are being used). However pyvenv does default to bootstrapping pip into the virtual environment which that particular feature *does* require ensurepip and the Wheel files. In Python 3.3 there is no ensurepip and pyvenv does not include pip, but feedback has overwhelmingly been that 3.3's pyvenv is useless because it does not provide any means of installing things into it like virtualenv does. This has lead people to continue to use virtualenv instead of pyvenv which can hopefully be rectified in 3.4+ now. Additionally it's important to remember that the only reason virtualenv itself works on Debian is because it violates the Debian policy and ships the Wheel files that I (as the person whose released the upstream virtualenv) included within it. The solution that Barry has with pyvenv is more complex than simply including those files as python-virtualenv does, however it is my understanding that is allows pyvenv to be compliant with Debian policy. > >> Wheels are a solution to a problem that is *explicitly* Debian, given >> the policy and DFSG violations vendorizing entails. Upstream doesn't >> have the same concern. > > (I think by “to vendorize” you mean “to bundle”. Why the neologism > “vendorize”, what is the distinction?) I think the general distinction is that bundling is more generic than vendoring. Vendoring typically refers to including the code of another package as part of the code of the primary package. For instance, pip vendors requests (and others) as pip._vendor.requests. It is effectively a part of the pip namespace now instead of simply bundling the two packages together so that installing pip also installs requests. > > What do wheels do which address Debian in particular? Why is it that > Debian can't ignore wheels as superfluous? Wheels don't address a problem that is specific to Debian, as I explained above we need a package to install into the virtual environment. As far as I am aware dpkg is not aware of virtual environments and I cannot install a package (such as python-pip) multiple times into multiple virtual environments on a single machine. So more accurately this solves a generic problem for which the typical Debian machinery does not have a solution for. > > -- > \ “It is well to remember that the entire universe, with one | > `\ trifling exception, is composed of others.” —John Andrew Holmes | > _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/85iooo2hez.fsf...@benfinney.id.au > - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
