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
