Re: wheel support for Debian?
[Barry Warsaw, 2014-05-16]
> Since you've mentioned this several times, I wonder if you can explain why you
> prefer it over the build-wheels-at-package-build-time approach?
* I don't want to promote .whl, .egg or anything else that is not even
remotely comparable to .rpm or .deb,
* I don't think we should force admins to learn anything other than
apt-get/deb. We should burn every egg, whl, gem, etc. that is not in
/usr/local or in ~/.local/ with fire!
We know whls are zip files, but admins do not have to know that.
If there's security issue (not yet fixed by Debian), do we want to
force them to learn how to change a file inside .whl file? They have
better things to do,
* I don't think we should force maintainers to do changes in their
packages if it's not really needed,
(not to mention additional work for ftpmasters)
* I don't think we should add redundant files to the archive if it
doesn't really gain that much
> A few things I worry about: since you won't be building the wheel from
> upstream (but quilt-patched) source tree, it's possible you'll have incomplete
> information and won't be able to build a wheel in the necessary format. You
> can't use bdist_wheel because you won't have a setup.py handy. You won't have
if wheel specification is so unclear that we have to use 3rd party
library (setuptools) to generate them, that worries me as well
> a dist-info directory handy (I think - and not sure if that matters). Because
> you won't be running from a setup.py, you won't know for sure what needs to go
> into the wheel, and you might have to track down files from several locations
we know what has to go to .deb package, we know exactly which files are
needed, we already provide egg-info/dist-info directories. If whls need
more than this, why not ship only these additional files instead of
complete .whl files?
> on the file system. It *might* all work, but if there are corner cases that
> cause your script to build incompatible wheels, it'll be tougher to track down
> and fix the problems. If you build the dependent wheels when someone creates
> a venv, it'll take longer, although if it's noticeable you could cache the
> results, except that's more machinery that could have bugs (e.g. evicting the
> cache when packages get updated). postinst and dpkg triggers are more
> "magical" and so more difficult for others to understand and contribute to,
> although good documentation can mitigate that. It also seems like more moving
> parts for something that is fundamentally pretty simple.
please at least unpack these wls files so that admins don't have to
figure out what to do with them if they want to apply a patch from
upstream
--
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: