Re: wheel support for Debian?
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
Reply to: