On May 19, 2014, at 12:19 PM, Piotr Ożarowski wrote: >* I don't want to promote .whl, .egg or anything else that is not even > remotely comparable to .rpm or .deb,
In fact, the second draft of the policy that I posted explicitly prohibits wheels except in some specific, described cases. >* 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, It should be rare to nonexistent for admins, or almost anyone, to *have* to know about the details of wheels. Remember, the wheels are only there for pip to function properly *inside* a virtual environment. Splitting out pythonX.Y-venv into a separate binary package means that none of this gets installed by default. Only people developing libraries and applications with Python will care at all, and I would mostly expect them to at least be able to understand wheels if necessary (such developers might even be building them themselves). >* 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) The additional ftpmasters work should happen once. All of the required packages are under DPMT maintenance, except six (now to be co-maintained by Colin and myself), distlib and setuptools (doko), and colorama (which has only seen NMUs after the initial upload and for which I have started the MIA process, intending to adopt it into DPMT). And of course python3.4. There's a README.venv in my python3.4 patch which describes exactly how the whole thing hangs together. Most people won't care, they'll just apt-get install python3-venv and be done with it. >* I don't think we should add redundant files to the archive if it > doesn't really gain that much I think it does gain us things. I gains simplicity of packaging, since all the pieces needed already exist upstream and are well tested, so the packaging changes are just a command and a .install file. It's also highly discoverable since the command is right there in the rules file. It's easier to debug. It's code we don't have to write, debug, and maintain. It means the delta for python3.4 is smaller, with more of a chance of getting those changes upstreamed. >if wheel specification is so unclear that we have to use 3rd party >library (setuptools) to generate them, that worries me as well PEP 427 describes the wheel format in detail. We could craft them ourselves, although I'm not sure why we'd want to when bdist_wheel already does it. Using setuptools just makes it all easier. >> 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? I have a working stack. We don't yet have working code for building the wheels on the fly. A practical solution would be to adopt the current approach now to fix a real bug that causes our users headaches. You can always work on the postinst wheel building code in the meantime and propose changing over to it if it proves to be clearly better. At least it wouldn't be a transition on the order of python-central or -support :). I don't favor the postinst approach, so I'm not volunteering to do that work. I also don't think we should hold up resolution of this issue. This isn't a permanent change we'll regret three years from now. Cheers, -Barry -- 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/20140519095522.49384...@anarchist.wooz.org
