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
Reply to: