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

[Elvis Stansvik]

Den tis 26 mars 2019 kl 15:20 skrev Phil Thompson <phil at riverbankcomputing.com>:
>
> 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.

Sigh of relief here. Thanks Phil. We pin our Qt version in CI
jobs/deployment, and bump it relatively rarely.

I think the EOL policy sounds sensible.

Elvis

>
> Phil
>
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt