[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 -- 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/20140519101939.gj4...@sts0.p1otr.com