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

[Elvis Stansvik]

Den lör 30 mars 2019 kl 16:29 skrev Elvis Stansvik <elvstone at gmail.com>:
>
> 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

s/Qt/PyQt/

Elvis

> 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