this wheel's on fire #61
Comments
|
Wheels are the new standard of Python distribution and are intended to replace eggs. TL;DR - A wheel is a zip-format archive with a specially formatted file name and the .whl extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time. When pip doesn't find a wheel for the requirement, it downloads the source dist and tries to build a wheel from it locally. If it succeeds, the wheel is stored in pip's cache for future reinstalls. if it fails, pip switches to the legacy installation from source dist (invoking I found my mistake, the |
Nice jam 🔥 PS: Should I create a PR for the change? similar to ratt-ru/radiopadre-client@b2df9a9 |
|
Ah ok, cool. I assume we'll need to make a pre5 release for this to make its way into PyPI? If so, please make a |
|
Duly. |
|
Elsewhere you say
...and I think you're right. Or to put it another way, I don't think radiopadre can be shipped as a wheel at all, in this incarnation. Because, as you quote above:
Which radiopadre clearly cannot be -- for instance, the step it's falling over at at the moment is when the setup script invokes jupyter to register a custom kernel -- well registering a kernel is not something that can be accomplished by dropping a bunch of files into site-packages. The root cause is, radiopadre is more than a set of Python packages and modules -- there are all these awkward add-ons -- so if wheels cannot accommodate, so be it. So I would say, don't worry about building a wheel -- rather figure out how to tell it not to build a wheel in the first place (of course I can add a |
This is exactly what I was thinking. Before I drop down the wheels please try installing the wheels and test so we can confirm that they will be of no use in this instance. You can run the following: |
|
@Athanaseus, just reading up on wheels -- if you install a wheel, at what point is It sounds to me that a custom script can only executed at wheel build time -- and the build may, in principle, be completely decoupled from wheel installation time, right? A wheel can be cached, and can be installed from cache into a completely new virtual environment, correct? If my interpretation is correct, then we can't use a wheel yet, as the custom setup script is not guaranteed to run in the new environment... |
Yes, this won't get executed.
Yes, that's correct.
100% sir. PS: I guess source distribution is the way here. Thanks 👍 |
|
You sort of want this: Where you'd have a second package that would solve the problems of the first package. But it's a mess... |
(For those too young to get the reference...)
So this currently happens when I pip install it, see below.
In summary, it tries to build a wheel for radiopadre, falls over because it can't find jupyter, then goes on to run setup.py for radiopadre normally, and succeeds in the end.
I don't fully (or even partially) understand WTF a wheel is, but it's clearly (a) entirely optional, (b) currently un-buildable, and so (c) should be disabled?
(Actually the same thing happens for pyregions or whatsit, but that's not our baby...)
The text was updated successfully, but these errors were encountered: