<div dir="ltr">I think this is a good example of the non-technical problems with the author-lead model of pypi and lack of a build farm detailed in <a href="https://pypackaging-native.github.io">https://pypackaging-native.github.io</a> are pushing requests for (significant) amounts of work back upstream to the projects.<div><br></div><div>I suspect that pixi will be able to handle these cases in a more reliable way (because it does the lock per-platform) and relies on conda-forge (rather than the projects) to build the binary artifacts.<br><div><br></div><div>Tom</div><div><div><br></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Sep 19, 2025 at 8:10 PM konstin <<a href="mailto:konstin@mailbox.org">konstin@mailbox.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 19.09.25 23:18, Phil Thompson wrote:<br>
> On 19/09/2025 09:43, konstin wrote:<br>
>> Hi,<br>
>><br>
>> I have a request regarding the packaging of PyQt5-Qt5 on PyPI.<br>
>><br>
>> Packaging tools such as uv or poetry resolve the user's dependencies,<br>
>> and then write the versions to a platform-independent lockfile. This<br>
>> is built under the assumption that a version can be used on any<br>
>> supported platform.<br>
><br>
> IMHO that is a really dumb assumption. Different platforms have <br>
> different capabilities. Different projects have different levels of <br>
> support on different platforms.<br>
><br>
> I understand that these tools are trying to create a cross-platform <br>
> environment, but there has to be cases where this is (for good <br>
> reasons) not possible. At the very least they should be able to see if <br>
> there is a set of versions that is able to meet the cross-platform <br>
> requirements (which there is in this case).<br>
<br>
I'm with you on this, and the resolver algorithms take this into <br>
account, for example when there's a conditional dependency to only use <br>
pywin32 in Windows. It's also supported to have e.g. ML applications <br>
that only run on Linux. There are also cases where this approach fails, <br>
notably when packages drop support for older platforms in newer <br>
releases. For PyQt5-Qt5, the trouble is that the platform support is <br>
split between multiple versions, all compatible with the user's <br>
requirements file. I'm aware of only two packages for which this is the <br>
case, that's why I decided to contact those two projects directly.<br>
<br>
>> PyQt5-Qt5 breaks this assumption as different versions have wheels for<br>
>> different platforms. For example, 5.15.2 has Windows wheels, while<br>
>> 5.15.17 has Linux and macOS wheels. Without a source distributions,<br>
>> package managers can't build missing wheels for a version. This leads<br>
>> to regular questions from users of both uv and poetry, see<br>
>> <a href="https://github.com/astral-sh/uv/issues?q=is%3Aissue%20%20pyqt5" rel="noreferrer" target="_blank">https://github.com/astral-sh/uv/issues?q=is%3Aissue%20%20pyqt5</a> and<br>
>> <a href="https://github.com/python-poetry/poetry/issues?q=is%3Aissue%20pyqt5" rel="noreferrer" target="_blank">https://github.com/python-poetry/poetry/issues?q=is%3Aissue%20pyqt5</a>,<br>
>> who get errors where the dependency resolution works, but installation<br>
>> fails because wheels are missing.<br>
>><br>
>> Would it be possible to always publish wheels for all supported<br>
>> platforms for PyQt5-Qt5?<br>
><br>
> The reason the Windows wheels are based on an older version of Qt is <br>
> that I haven’t yet put the effort into building from source. I plan to <br>
> get around to it at some point but it’s not a priority.<br>
><br>
I totally understand that external build tooling related problems are <br>
hard to prioritize.<br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Thomas Caswell<br><a href="mailto:tcaswell@gmail.com" target="_blank">tcaswell@gmail.com</a></div>