Re: wheel support for Debian?
Hi Piotr,
On May 16, 2014, at 10:48 AM, Piotr Ożarowski wrote:
>If I provide a script that generates .whl file out of Debian binary
>package, would that make more sense than these -wheels packages?
>
>python3.X-venv could simply depend on required packages and run this
>script (with a list of required dependencies) when someone creates new
>venv. You can also pre-generate them in python3.X-venv's postinst but
>then a dpkg trigger is needed to regenerate them when one of
>dependencies is upgraded.
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?
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
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
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.
I'm still in favor of the simple current approach (modulo bikeshedding on some
details). But I'd like to better understand why you favor the postinst
approach over the build-time approach.
Cheers,
-Barry
Reply to: