Some questions about next versions of SIP

[Phil Thompson]

On 15/09/2020 19:14, Dmitry Shachnev wrote:
> Hi Phil, and thanks for your reply,
> 
> On Mon, Sep 14, 2020 at 10:23:39PM +0100, Phil Thompson wrote:
>> There will be no more SIP v4 or v5 releases after v6 is released. SIP 
>> v4 has
>> been deprecated for more than a year. *Nobody* should still be using 
>> it.
> 
> Unfortunately, in Debian there are still around 20 packages using it.
> 
> I was going to migrate them to SIP v5 and using sip5 tool (because I 
> don't
> have enough time to port them all to the new build system myself), but 
> now
> that SIP v6 won't have that legacy tool and SIP v5 won't be installable
> together with SIP v6, probably I will have to change my plan and let 
> them
> remain on v4 until someone ports them to the new build system.
> 
> So it would be really nice if tools built with SIP v4 are still 
> compatible
> with PyQt5 built with SIP v5/v6.

I can't think of any reason why that would not be the case.

>> > - Is it possible to mix different SIP versions in the same project?
>> >   For example, some upstreams (like Calibre) can be built only with SIP
>> >   v4, but is it fine to use these projects together with PyQt5 that is
>> >   built with newer sip?
>> 
>> Yes, assuming the exact version of SIP v4 is relatively recent. SIP v4 
>> only
>> supports one (major/minor) version of the ABI. SIP v5 supports all 
>> versions
>> of the ABI with the project specifying which version it wants to use.
> 
> The exact version is the latest one, 4.19.24. However the ABI version 
> is
> still different from what PyQt5 is built with (12.7 vs. 12.8). I guess 
> it's
> fine?

Yes. The ABI uses semantic versioning.

> And what if PyQt5 ABI changes to 13.0 — will it be still fine?

PyQt5 will never use ABI v13. If a future version of PyQt5 needs new SIP 
features in the sip module then I'll introduce ABI v12.9.

>> > - Is there any migration guide how to switch to sipbuild for projects that
>> >   are calling sip or sip5 executable from their custom build system? For
>> >   example, Krita and QGIS are such projects, they are calling sip/sip5
>> >   from their CMake-based build system.
>> >
>> >   Ideally it would be nice to have a guide that would also cover other
>> >   aspects of updating to a newer SIP, such as API changes.
>> 
>> The main difference between SIP v4 and v5 is the *addition* of a build
>> system, so it's not possible to write a guide to converting from 
>> something I
>> know nothing about.
> 
> I was thinking about something like that: “If you were calling sip with 
> these
> command line options, add this to your pyproject.toml / whatever file.”
> 
> I don't personally need this, but having such documentation may help to
> convince some upstreams to port to new build system.
> 
>> > - Will SIP v5 and SIP v6 be co-installable? Or both will use the same
>> >   Python module name (sipbuild) and the same set of binaries (sip-build &
>> >   friends)? I am asking this because I will have to continue shipping
>> >   older versions of SIP for packages that are using sip5 legacy tool.
>> 
>> No, but one approach a project might take is to implement something 
>> similar
>> to the sip5 legacy tool that uses the documented sipbuild API. I'd be 
>> happy
>> to refine that API to make that easier - but I'm not providing a sip6 
>> legacy
>> tool.
> 
> If a copy of sipbuild/legacy/sip5.py will work with SIP v6 without many
> changes, that would be nice indeed.

It wouldn't be a copy it would be a new implementation using the 
(possibly enhanced) public sipbuild API.

Phil