[PyQt] RFQ on PyQt End-of-Life Policy

Phil Thompson phil at riverbankcomputing.com
Tue Mar 26 14:20:15 GMT 2019

On 26/03/2019 11:45, Dark Penguin wrote:
>>> I also remove the previous wheels from PyPI but I’ve never been sure
>>> that that’s the right thing to do.
>> Matter of personal taste, but I would leave everything on PyPI
>> once it's an official release.
> I may be mistaken due to being a Python beginner, but wouldn't removing
> wheels break virtualenv "freeze" functionality?.. Or at least cause
> "different packages at different time points". Because "freeze" tries 
> to
> restore all packages to the exact saved version.
> As far as I understand, it is a very common practice to use "freeze" to
> restore all the environment to the exact same configuration as it was
> before, which may sometimes be essential for development and packaging
> purposes. At the very least, that would cause additional inconvenience
> for developers, maintainers and CI/CD people all around, who can not 
> use
> their "previously working" configuration due to PyQt being 
> unforgivingly
> progressive. :)

That’s a good point that I hadn’t considered.

> Also, the latest releases might probably be generally oriented towards
> the latest Ubuntu, but we also have Debian Stable, which may not even
> have a reasonably modern C++ compiler. And I'm still on oldstable, 
> where
> you can't even install PyQt5 from pip at all due to the absence of
> sip>=4.19.1 which apparently does not have a wheel for Python 3.4 (what
> happened to supporting all Python versions?.. And shouldn't PyQt 5.8.0
> depend on an older version of sip?).

By support I mean source code support not distribution packages.

> Of course, I don't suggest that supporting oldstable makes sense, and I
> support the decision to drop support for old Python versions. But I
> think that simply keeping the old wheels could help avoid various
> problems in a lot of corner cases. I would also ask to keep the old
> sources - if not on the website, then at least on some FTP archive 
> where
> they can be found if you really need them; however, I can't come up 
> with
> a good, justifiable example of a specific corner case that would 
> benefit
> from this.
> One possible case is the situation with the Android NDK:
> - Google does something questionable like removing GCC from the NDK;
> - something in my project does not compile with Clang just yet;
> - recent PyQt versions dropped support for GCC or older NDK;
> - I really need to just keep things working for a while, but my new
> contributors can't even build my project because the old wheels are not
> in pip anymore.
> This particular example may not be very good, but the idea is that
> simply not deleting something seemingly useless may give more options 
> to
> people struggling with some unexpected problems - even if it's just
> someone using outdated software and "unsupported and not recommended,
> but still possible" solutions.

It’s Ok you’ve convinced me not to remove the old wheels in future.


More information about the PyQt mailing list