Please publish release with packages for all platforms for PyQt5-Qt5

Thomas Caswell tcaswell at gmail.com
Mon Sep 22 22:24:39 BST 2025


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
https://pypackaging-native.github.io are pushing requests for (significant)
amounts of work back upstream to the projects.

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.

Tom


On Fri, Sep 19, 2025 at 8:10 PM konstin <konstin at mailbox.org> wrote:

>
> On 19.09.25 23:18, Phil Thompson wrote:
> > On 19/09/2025 09:43, konstin wrote:
> >> Hi,
> >>
> >> I have a request regarding the packaging of PyQt5-Qt5 on PyPI.
> >>
> >> Packaging tools such as uv or poetry resolve the user's dependencies,
> >> and then write the versions to a platform-independent lockfile. This
> >> is built under the assumption that a version can be used on any
> >> supported platform.
> >
> > IMHO that is a really dumb assumption. Different platforms have
> > different capabilities. Different projects have different levels of
> > support on different platforms.
> >
> > I understand that these tools are trying to create a cross-platform
> > environment, but there has to be cases where this is (for good
> > reasons) not possible. At the very least they should be able to see if
> > there is a set of versions that is able to meet the cross-platform
> > requirements (which there is in this case).
>
> I'm with you on this, and the resolver algorithms take this into
> account, for example when there's a conditional dependency to only use
> pywin32 in Windows. It's also supported to have e.g. ML applications
> that only run on Linux. There are also cases where this approach fails,
> notably when packages drop support for older platforms in newer
> releases. For PyQt5-Qt5, the trouble is that the platform support is
> split between multiple versions, all compatible with the user's
> requirements file. I'm aware of only two packages for which this is the
> case, that's why I decided to contact those two projects directly.
>
> >> PyQt5-Qt5 breaks this assumption as different versions have wheels for
> >> different platforms. For example, 5.15.2 has Windows wheels, while
> >> 5.15.17 has Linux and macOS wheels. Without a source distributions,
> >> package managers can't build missing wheels for a version. This leads
> >> to regular questions from users of both uv and poetry, see
> >> https://github.com/astral-sh/uv/issues?q=is%3Aissue%20%20pyqt5 and
> >> https://github.com/python-poetry/poetry/issues?q=is%3Aissue%20pyqt5,
> >> who get errors where the dependency resolution works, but installation
> >> fails because wheels are missing.
> >>
> >> Would it be possible to always publish wheels for all supported
> >> platforms for PyQt5-Qt5?
> >
> > The reason the Windows wheels are based on an older version of Qt is
> > that I haven’t yet put the effort into building from source. I plan to
> > get around to it at some point but it’s not a priority.
> >
> I totally understand that external build tooling related problems are
> hard to prioritize.
>


-- 
Thomas Caswell
tcaswell at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20250922/31fc59e5/attachment.htm>


More information about the PyQt mailing list