Hi Stuart On Thu, 12 Mar 2026 at 01:26, Stuart Prescott <[email protected]> wrote: > > pyside6 appears on neither of the two Python 3.14 transition trackers > > [1][2]. I think that the binary packages should have (generated) > > versioned dependencies on python3. > > Perhaps I've missed something here - I don't believe that PySide6 has a > specific dependency on the Python version that it is being used with. > (That is, other than whatever incompatibilities might arise between > Python interpreter releases, just the same as we have with all Python > packages.) The .so it compiles are all ABI3, indicating cross > interpreter support.
That's great! If there's no need for pyside6 to be rebuilt, then there's no need for it to appear on either of the trackers, and adding the versioned dependencies would only be a way to get it there. I was looking at packages migrating from pyside2 to pyside6, and noticed that pyside2 appeared on the python3.14-default tracker, and pyside6 did not. I tried to rebuild it, which led to this bug report. I'll keep my answers below brief, but perhaps this discussion should continue on the mailing list. > I can see from a RT perspective that not testing against the non-default > Python interpreters is suboptimal - having a signal that packages work > so the transition is good to proceed is valuable. I don't think testing with both versions matters to RT, we only release with one. > - Do we not already get that from the experimental pseudo-excuses use of > ci.d.n for the 3.XY-defaults transitions? I don't think the pseudo-excuses really help with transitions (i.e. when packages need to be rebuilt). > - Would adding an extra set of `flaky` tests for non-default > interpreters be a useful middle ground for this? Off the top of my head, I don't think so. > - Or would you rather see that import test against all supported > interpreters (and see if we regret that when we get to Python 3.15)? I'd rather see more packages being built for all supported versions (i.e. appearing on python3.14-add) and fewer only being built for the default version (i.e. appearing on python3.14-default). This would allow more packages to migrate as soon as they are ready, and not have so much being blocked. Regards Graham
