Re: sponsorship request
* Thomas Goirand , 2014-05-07, 14:29:
Same remark also for the binary Depends: of python-django-piston. But
this time, if dh_python2 (see below) automatically adds the
dependencies by replacing ${python:Depends}, then probably you can
completely remove the manual dependencies (this will have to be checked
after a build, for example using "mc" to see the content of the .deb,
and going into the DEBIAN folder).
I find debc(1) very convenient for checking whether the built binary
packages make sense.
--
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/20140507065832.ga2...@jwilk.net
Re: sponsorship request
On 05/06/2014 01:57 AM, Christophe Siraut wrote:
> Hi,
>
> I worked on the following bugs and need a quality review:
>
> - #705275 ITA: python-django-contact-form -- extensible contact-form
>application for Django
> - #686171 python-django-piston: Django 1.4 compatibility [RC]
>
> You can check them out on the team repository, see [1]. Comments are welcome,
> note I have not much experience in packaging.
>
> Is someone willing to upload these to the archive when ready?
>
> Thank you,
> Christophe
>
> 1.
> svn+ssh://svn.debian.org/svn/python-modules/packages/python-django-contact-form
> svn+ssh://svn.debian.org/svn/python-modules/packages/python-django-piston
Hi Christophe,
A few remarks on the python-django-piston package.
1/ debian/control
The package build-depends on python (>= 2.4). It's been a long long time
since we don't have such old python version in Debian, so the >= 2.4
part isn't needed. Instead, you should build-depend on python-all (that
is, all version of Python 2.x available, which means 2.7 for when
building in Sid / Testing, and 2.6 + 2.7 in Wheezy if someone writes a
backport).
Same remark for python-setuptools (>= 0.6.10). Even squeeze has
python-setuptools 0.6.14, so no need to version-depends on it.
Same remark also for the binary Depends: of python-django-piston. But
this time, if dh_python2 (see below) automatically adds the dependencies
by replacing ${python:Depends}, then probably you can completely remove
the manual dependencies (this will have to be checked after a build, for
example using "mc" to see the content of the .deb, and going into the
DEBIAN folder).
The package is build-depend-indep on python-support. This is now
deprecated, and we are trying to completely get rid of it. Please read this:
https://wiki.debian.org/Python/TransitionToDHPython2
and follow the steps to transition to dh_python2 / dh_python3.
Please bump Standards-Version: to 3.9.5.
2/ debian/copyright
It's not mandatory, but it'd be nice to convert your copyright file into
the parseable format 1.0 as per the specs here:
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
there's loads of examples in the archive that will show you how to do it
(take any of the OpenStack team packages for example).
3/ debian/source.lintian-overrides
I don't see why there's such overrides. IMO, the issue should be fixed
rather than overriden. What's weird is that there's "svn-upgrade"
defined in the debian/watch as repack script, but I couldn't find it in
the SVN repository. Please address this issue and make a working repack
script to clean the upstream tarball of useless hg files.
There's maybe other problems, but I've stopped my review here.
If you modify this package, I'll have a look again. I never review 2
packages at once, because it's often the case that the sponsoree does
the same mistakes on both, so I'll have a look on the 2nd one only if
the first one is cleaned and I have uploaded it.
I hope this helps,
thanks for contributing to Debian,
Cheers,
Thomas Goirand (zigo)
--
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/5369d2d8.5020...@debian.org
Re: Bug #732703 and fixing ensurepip/pyvenv
On May 06, 2014, at 06:39 PM, Donald Stufft wrote: >For what it’s worth, I’m the one who pushed hard against ZipImport >capabilities being codified in PEP427 and I can say that we are *incredibly* >unlikely to remove that ability without introducing a better way of achieving >that. So even if the current method breaks, there is almost certainly going >to be a path forward. Cool. One other thing you mentioned in IRC as an argument against unpacking, is that if you did unpack, you'd also have to remove dist-info directories. -Barry signature.asc Description: PGP signature
Re: Bug #732703 and fixing ensurepip/pyvenv
On May 6, 2014, at 6:28 PM, Barry Warsaw wrote: > PEP 427 does discourage direct import from wheels[1] but for the things we > care about immediately, the two conditions should not affect us (i.e. no C > extensions, and no bad use of __file__) so I think we could get away with it. > I'm open to other good arguments for or against using the wheels directly. For what it’s worth, I’m the one who pushed hard against ZipImport capabilities being codified in PEP427 and I can say that we are *incredibly* unlikely to remove that ability without introducing a better way of achieving that. So even if the current method breaks, there is almost certainly going to be a path forward. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail
Bug #732703 and fixing ensurepip/pyvenv
I have been doing some experimentation and preparation for trying to solve bug #732703, i.e. fixing ensurepip in Python 3.4 and thus the pyvenv command. Why this is tricky: ensurepip in the Python stdlib bundles two wheels, one for setuptools and another for pip, and these wheels get installed into the virtual environment. ensurepip does this to ease the installation process and to only have to rely on known compatible versions of the libraries. Further, pip itself bundles (a.k.a. vendorizes) several packages itself, such as colorama, distlib, html5lib, requests, and six. pip does this to also rely on known dependency versions, but also to prevent upgrades to e.g. requests breaking pip itself. To make matters worse, requests also vendorizes packages such as chardet, charade, and urllib3. It's a recursive mess. All this vendorizing causes problems because it violates Debian policy. When we package up e.g. requests for Debian, we *unvendorize* everything (through quilt patches mostly) so that when requests imports urllib3, it does so from the python*-urllib3 Debian package. It's then our job to ensure compatible versions across the board, but that's what a distro does. ensurepip and thus pyvenv is disabled in Debian's Python 3.4 because unwinding all this vendorizing is a huge PITA. I think I have an approach that might be acceptable, and could possibly work. I haven't fully implemented it, but some experimentation makes me think it's not too horrible. I'd like to get your feedback before spending much more time on it. If it seems generally acceptable, I'll continue to work on the stack of things we'll need. The idea generally is to create PEP 427 wheels out of all the dependencies *from the packages in the archive at build time*. We add a new binary package to the source package, something like python--wheels, and these drop the .whl files into /usr/share/python-wheels. Thus, most people can ignore the -wheels packages entirely with no change to their code or packaging. For a few things that need it, e.g. python3.4, we Build-Depend on the appropriate -wheel binary packages and add a Built-Using field to d/control to so indicate the package version we're depending on. Then we recursively rebuild the ensurepip embedded .whl files from contents in /usr/share/python-wheels. This guarantees that all the embedded stuff is at least built from source that is in the archives. From Python import's point of view, we'll still be vendorizing, but now we'll be vendorizing wheels, and we could either copy the .whl file in place, or Depends on the -wheel packages and symlink to the appropriate /usr/share/python-wheels/*.whl file. We would have to modify some __init__.py files to set up importing from the vendorized .whl. We *could* unpack the wheel into place (it's just a zip file after all), but I rather like that vendorized packages are self-contained. It seems cleaner. PEP 427 does discourage direct import from wheels[1] but for the things we care about immediately, the two conditions should not affect us (i.e. no C extensions, and no bad use of __file__) so I think we could get away with it. I'm open to other good arguments for or against using the wheels directly. The __init__.py code we'd have to add would be pretty minimal: -snip snip- import os here = os.path.dirname(__file__) for filename in os.listdir(here): if os.path.splitext(filename)[1] == '.whl': __path__.append(os.path.join(here, filename)) -snip snip- E.g. this would go in pip/_vendor/__init__.py and then when you `import pip._vendor.six` it would come from pip/_vendor/six-1.6.1-py2.py3-none-any.whl 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.) It's still a lot of work to upload new packages (not all of which are team maintained) and test out the full stack. No doubt there are lots of things I'm missing, plenty of gotchas lurking, and maybe the whole idea is plain ol' stupid. But maybe it'll be just good enough to fix ensurepip and pyvenv. Feedback welcome, -Barry [1] http://tinyurl.com/n3p5psl signature.asc Description: PGP signature
