Some questions about next versions of SIP

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Some questions about next versions of SIP

Dmitry Shachnev
Hi Phil!

I noticed that you are preparing a new major version of SIP in hg — v6.

So I want to ask some questions that are relevant for me as a downstream
packager (Debian/Ubuntu).

- Will PyQt5 be switched to SIP v6 too? Or it is only for PyQt6?

- When (approximately) you are planning to release SIP v6? Will it happen
  in a few weeks, months or years? Or not before Qt 6.0 is released?

- Will SIP v5 (and maybe also v4) be supported after v6 is released?
  For example, now you are still making 4.19.x releases, but for how long
  will you do that?

- 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?

- 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.

- 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.

Sorry for many questions, but it's important for me to plan my work on distro
packages for SIP and PyQt.

--
Dmitry Shachnev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Phil Thompson-5
On 14/09/2020 19:09, Dmitry Shachnev wrote:
> Hi Phil!
>
> I noticed that you are preparing a new major version of SIP in hg — v6.
>
> So I want to ask some questions that are relevant for me as a
> downstream
> packager (Debian/Ubuntu).
>
> - Will PyQt5 be switched to SIP v6 too? Or it is only for PyQt6?

PyQt5 will be fine with SIP v6. The main point of SIP v6 is to remove
support for all deprecated features (including unsupported versions of
Python). PyQt5 no longer uses those deprecated features.

> - When (approximately) you are planning to release SIP v6? Will it
> happen
>   in a few weeks, months or years? Or not before Qt 6.0 is released?

The first snapshots will be in a week or two. v6.0.0 will be released
when PyQt6 is released, which will be when Qt6 is released.

> - Will SIP v5 (and maybe also v4) be supported after v6 is released?
>   For example, now you are still making 4.19.x releases, but for how
> long
>   will you do that?

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.

> - 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.

> - 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.

There may be improvements that can be made to help projects move to SIP
v5, but it is up to those projects to identify them.

> - 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.

> Sorry for many questions, but it's important for me to plan my work on
> distro
> packages for SIP and PyQt.

No problem, ask as many questions as you want.

Phil
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Boudewijn Rempt
On Monday, 14 September 2020 23:23:39 CEST Phil Thompson wrote:

> 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.

Well, it's not complicated. We run a cmake configure_command and build_command on the downloaded sip code:

        CONFIGURE_COMMAND ${PYTHON_EXECUTABLE_PATH} <SOURCE_DIR>/configure.py -b ${PREFIX_ext_sip}/bin -d ${PREFIX_ext_sip}/lib/python3.8/site-packages -e ${PREFIX_ext_sip}/include  --sipdir ${PREFIX_ext_sip}/sip --target-py-version 3.8 --sip-module PyQt5.sip
        BUILD_COMMAND make

For PyQt it's the same:

        CONFIGURE_COMMAND ${PYTHON_EXECUTABLE_PATH} <SOURCE_DIR>/configure.py ${_PYQT_conf}
        BUILD_COMMAND make

We cannot use any prebuilt binaries because we need to use our own build of Qt.
 
> There may be improvements that can be made to help projects move to SIP
> v5, but it is up to those projects to identify them.


--
https://www.krita.org


Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Phil Thompson-5
On 15/09/2020 07:36, Boudewijn Rempt wrote:

> On Monday, 14 September 2020 23:23:39 CEST Phil Thompson wrote:
>
>> 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.
>
> Well, it's not complicated. We run a cmake configure_command and
> build_command on the downloaded sip code:
>
>         CONFIGURE_COMMAND ${PYTHON_EXECUTABLE_PATH}
> <SOURCE_DIR>/configure.py -b ${PREFIX_ext_sip}/bin -d
> ${PREFIX_ext_sip}/lib/python3.8/site-packages -e
> ${PREFIX_ext_sip}/include  --sipdir ${PREFIX_ext_sip}/sip
> --target-py-version 3.8 --sip-module PyQt5.sip
>         BUILD_COMMAND make
>
> For PyQt it's the same:
>
>         CONFIGURE_COMMAND ${PYTHON_EXECUTABLE_PATH}
> <SOURCE_DIR>/configure.py ${_PYQT_conf}
>         BUILD_COMMAND make
>
> We cannot use any prebuilt binaries because we need to use our own
> build of Qt.
>
>> There may be improvements that can be made to help projects move to
>> SIP
>> v5, but it is up to those projects to identify them.

So I need to clarify a previous answer. PyQt5 will not work with SIP v6
if you are still using configure.py.

Phil
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Kovid Goyal
So, I looked into moving calibre's build system to use sip5 +
sip-install and am currently stuck with the following:

I want to install PyQt and PyQtWebEngine using sip-install

I need the install to happen to a staging directory from where I will
copy the files to the final installation directory. This works fine
for PyQt with --target-dir

However, if I specify --target-dir for PyQtWebEngine, it fails to find
the needed PyQt sip files. If I dont, then it installs directly into the
python site-packags directory.

So I need someway to either add a path to sip_include_dirs when callig
sip-install, or have some option that overrides where it installs,
without changing where it looks for sip files.

Kovid.

On Tue, Sep 15, 2020 at 09:27:02AM +0100, Phil Thompson wrote:

> On 15/09/2020 07:36, Boudewijn Rempt wrote:
> > On Monday, 14 September 2020 23:23:39 CEST Phil Thompson wrote:
> >
> > > 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.
> >
> > Well, it's not complicated. We run a cmake configure_command and
> > build_command on the downloaded sip code:
> >
> >         CONFIGURE_COMMAND ${PYTHON_EXECUTABLE_PATH}
> > <SOURCE_DIR>/configure.py -b ${PREFIX_ext_sip}/bin -d
> > ${PREFIX_ext_sip}/lib/python3.8/site-packages -e
> > ${PREFIX_ext_sip}/include  --sipdir ${PREFIX_ext_sip}/sip
> > --target-py-version 3.8 --sip-module PyQt5.sip
> >         BUILD_COMMAND make
> >
> > For PyQt it's the same:
> >
> >         CONFIGURE_COMMAND ${PYTHON_EXECUTABLE_PATH}
> > <SOURCE_DIR>/configure.py ${_PYQT_conf}
> >         BUILD_COMMAND make
> >
> > We cannot use any prebuilt binaries because we need to use our own build
> > of Qt.
> >
> > > There may be improvements that can be made to help projects move to
> > > SIP
> > > v5, but it is up to those projects to identify them.
>
> So I need to clarify a previous answer. PyQt5 will not work with SIP v6 if
> you are still using configure.py.
>
> Phil
>

--
_____________________________________

Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Kovid Goyal
Best I can come up with is to use sip-build and install manually myself

On Tue, Sep 15, 2020 at 10:12:55PM +0530, Kovid Goyal wrote:

> So, I looked into moving calibre's build system to use sip5 +
> sip-install and am currently stuck with the following:
>
> I want to install PyQt and PyQtWebEngine using sip-install
>
> I need the install to happen to a staging directory from where I will
> copy the files to the final installation directory. This works fine
> for PyQt with --target-dir
>
> However, if I specify --target-dir for PyQtWebEngine, it fails to find
> the needed PyQt sip files. If I dont, then it installs directly into the
> python site-packags directory.
>
> So I need someway to either add a path to sip_include_dirs when callig
> sip-install, or have some option that overrides where it installs,
> without changing where it looks for sip files.
>
> Kovid.
>
> On Tue, Sep 15, 2020 at 09:27:02AM +0100, Phil Thompson wrote:
> > On 15/09/2020 07:36, Boudewijn Rempt wrote:
> > > On Monday, 14 September 2020 23:23:39 CEST Phil Thompson wrote:
> > >
> > > > 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.
> > >
> > > Well, it's not complicated. We run a cmake configure_command and
> > > build_command on the downloaded sip code:
> > >
> > >         CONFIGURE_COMMAND ${PYTHON_EXECUTABLE_PATH}
> > > <SOURCE_DIR>/configure.py -b ${PREFIX_ext_sip}/bin -d
> > > ${PREFIX_ext_sip}/lib/python3.8/site-packages -e
> > > ${PREFIX_ext_sip}/include  --sipdir ${PREFIX_ext_sip}/sip
> > > --target-py-version 3.8 --sip-module PyQt5.sip
> > >         BUILD_COMMAND make
> > >
> > > For PyQt it's the same:
> > >
> > >         CONFIGURE_COMMAND ${PYTHON_EXECUTABLE_PATH}
> > > <SOURCE_DIR>/configure.py ${_PYQT_conf}
> > >         BUILD_COMMAND make
> > >
> > > We cannot use any prebuilt binaries because we need to use our own build
> > > of Qt.
> > >
> > > > There may be improvements that can be made to help projects move to
> > > > SIP
> > > > v5, but it is up to those projects to identify them.
> >
> > So I need to clarify a previous answer. PyQt5 will not work with SIP v6 if
> > you are still using configure.py.
> >
> > Phil
> >
>
> --
> _____________________________________
>
> Dr. Kovid Goyal
> https://www.kovidgoyal.net
> https://calibre-ebook.com
> _____________________________________
>

--
_____________________________________

Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Dmitry Shachnev
In reply to this post by Phil Thompson-5
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.

> > - 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?

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

> > - 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.

--
Dmitry Shachnev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Dmitry Shachnev
In reply to this post by Kovid Goyal
Hi Kovid!

On Tue, Sep 15, 2020 at 10:12:55PM +0530, Kovid Goyal wrote:
> So, I looked into moving calibre's build system to use sip5 +
> sip-install and am currently stuck with the following:
>
> [...]

I cannot answer your question, but I just want to thank you for looking at
the SIP v5 port of Calibre. It is currently the largest (and most popular)
package in Debian that is still using SIP v4.

https://github.com/kovidgoyal/calibre/commit/a4df5cc67ba6ee82 makes things
a bit better, I have notified our maintainer about that commit. Of course,
using the new build system (with pyproject.toml, etc.) would be even better.

--
Dmitry Shachnev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Phil Thompson-5
In reply to this post by Dmitry Shachnev
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
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Kovid Goyal
In reply to this post by Dmitry Shachnev
On Tue, Sep 15, 2020 at 09:28:34PM +0300, Dmitry Shachnev wrote:

> Hi Kovid!
>
> On Tue, Sep 15, 2020 at 10:12:55PM +0530, Kovid Goyal wrote:
> > So, I looked into moving calibre's build system to use sip5 +
> > sip-install and am currently stuck with the following:
> >
> > [...]
>
> I cannot answer your question, but I just want to thank you for looking at
> the SIP v5 port of Calibre. It is currently the largest (and most popular)
> package in Debian that is still using SIP v4.

I'm actually a bit surprised you have not run into the same issue
yourself while packaging. How do you get pyqtwebengine installing into a
staging area? Thankfully I dont actually need pyqtwebengine's SIP
files/pyi files/toml files so I will just use sip-build an manually copy
out the three .so file and leave the junk behind.

>
> https://github.com/kovidgoyal/calibre/commit/a4df5cc67ba6ee82 makes things
> a bit better, I have notified our maintainer about that commit. Of course,
> using the new build system (with pyproject.toml, etc.) would be even better.
>

calibre is never going to use pyproject.toml, but I will have its build
system use sip-build to build its PyQt extensions (it will essentially
generate a fake project and call sip-build on that) and copy out the
.so files.


--
_____________________________________

Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Kovid Goyal
In reply to this post by Kovid Goyal
On Tue, Sep 15, 2020 at 10:46:30PM +0530, Kovid Goyal wrote:
> Best I can come up with is to use sip-build and install manually myself

That's what I ended up doing. Another question, how do I get sip-build
to use multiple CPU cores? With configure.py there was -j there doesnt seem
to be any equivalent in sip-build. Makes building PyQt unnecessarily
slow.

--
_____________________________________

Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Eli Schwartz
In reply to this post by Kovid Goyal
On 9/15/20 10:43 PM, Kovid Goyal wrote:

> On Tue, Sep 15, 2020 at 09:28:34PM +0300, Dmitry Shachnev wrote:
>> Hi Kovid!
>>
>> On Tue, Sep 15, 2020 at 10:12:55PM +0530, Kovid Goyal wrote:
>>> So, I looked into moving calibre's build system to use sip5 +
>>> sip-install and am currently stuck with the following:
>>>
>>> [...]
>>
>> I cannot answer your question, but I just want to thank you for looking at
>> the SIP v5 port of Calibre. It is currently the largest (and most popular)
>> package in Debian that is still using SIP v4.
>
> I'm actually a bit surprised you have not run into the same issue
> yourself while packaging. How do you get pyqtwebengine installing into a
> staging area? Thankfully I dont actually need pyqtwebengine's SIP
> files/pyi files/toml files so I will just use sip-build an manually copy
> out the three .so file and leave the junk behind.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/pyqtwebengine#n20

Currently uses sip-build, make, make INSTALL_ROOT="$pkgdir" install


>> https://github.com/kovidgoyal/calibre/commit/a4df5cc67ba6ee82 makes things
>> a bit better, I have notified our maintainer about that commit. Of course,
>> using the new build system (with pyproject.toml, etc.) would be even better.
>>
>
> calibre is never going to use pyproject.toml, but I will have its build
> system use sip-build to build its PyQt extensions (it will essentially
> generate a fake project and call sip-build on that) and copy out the
> .so files.

I rather figured pyproject.toml was extremely surplus to requirements
for a project that isn't a PyPI module and builds in the manner of a
complex system program that merely happens to be *mostly* python, so
this does not surprise me at all. :)

--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Kovid Goyal
Thanks, Eli. --no-make looks like the missing piece. With it I can
even parallelize the build.

On Tue, Sep 15, 2020 at 11:20:56PM -0400, Eli Schwartz wrote:

> On 9/15/20 10:43 PM, Kovid Goyal wrote:
> > On Tue, Sep 15, 2020 at 09:28:34PM +0300, Dmitry Shachnev wrote:
> >> Hi Kovid!
> >>
> >> On Tue, Sep 15, 2020 at 10:12:55PM +0530, Kovid Goyal wrote:
> >>> So, I looked into moving calibre's build system to use sip5 +
> >>> sip-install and am currently stuck with the following:
> >>>
> >>> [...]
> >>
> >> I cannot answer your question, but I just want to thank you for looking at
> >> the SIP v5 port of Calibre. It is currently the largest (and most popular)
> >> package in Debian that is still using SIP v4.
> >
> > I'm actually a bit surprised you have not run into the same issue
> > yourself while packaging. How do you get pyqtwebengine installing into a
> > staging area? Thankfully I dont actually need pyqtwebengine's SIP
> > files/pyi files/toml files so I will just use sip-build an manually copy
> > out the three .so file and leave the junk behind.
>
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/pyqtwebengine#n20
>
> Currently uses sip-build, make, make INSTALL_ROOT="$pkgdir" install
>
>
> >> https://github.com/kovidgoyal/calibre/commit/a4df5cc67ba6ee82 makes things
> >> a bit better, I have notified our maintainer about that commit. Of course,
> >> using the new build system (with pyproject.toml, etc.) would be even better.
> >>
> >
> > calibre is never going to use pyproject.toml, but I will have its build
> > system use sip-build to build its PyQt extensions (it will essentially
> > generate a fake project and call sip-build on that) and copy out the
> > .so files.
>
> I rather figured pyproject.toml was extremely surplus to requirements
> for a project that isn't a PyPI module and builds in the manner of a
> complex system program that merely happens to be *mostly* python, so
> this does not surprise me at all. :)
>
> --
> Eli Schwartz
> Arch Linux Bug Wrangler and Trusted User
>




--
_____________________________________

Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Phil Thompson-5
In reply to this post by Kovid Goyal
On 16/09/2020 04:19, Kovid Goyal wrote:
> On Tue, Sep 15, 2020 at 10:46:30PM +0530, Kovid Goyal wrote:
>> Best I can come up with is to use sip-build and install manually
>> myself
>
> That's what I ended up doing. Another question, how do I get sip-build
> to use multiple CPU cores? With configure.py there was -j there doesnt
> seem
> to be any equivalent in sip-build. Makes building PyQt unnecessarily
> slow.

You can run sip-build with --no-make and run make separately. Or I can
add an option. I'm happy to add options, features etc. to fix gaps in
the current implementation.

Phil
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Florian Bruhin
In reply to this post by Phil Thompson-5
Hey,

I also have a question I haven't seen in this thread yet: IIRC there
were plans to rewrite the code generation part of SIP in Python. Is this
going to be a part of SIP v6 as well, or is this for "somewhen later"?

Florian

--
[hidden email] (Mail/XMPP) | https://www.qutebrowser.org 
       https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
       GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
             I love long mails! | https://email.is-not-s.ms/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Florian Bruhin
In reply to this post by Phil Thompson-5
On Wed, Sep 16, 2020 at 09:31:27AM +0100, Phil Thompson wrote:

> On 16/09/2020 04:19, Kovid Goyal wrote:
> > On Tue, Sep 15, 2020 at 10:46:30PM +0530, Kovid Goyal wrote:
> > > Best I can come up with is to use sip-build and install manually
> > > myself
> >
> > That's what I ended up doing. Another question, how do I get sip-build
> > to use multiple CPU cores? With configure.py there was -j there doesnt
> > seem
> > to be any equivalent in sip-build. Makes building PyQt unnecessarily
> > slow.
>
> You can run sip-build with --no-make and run make separately. Or I can add
> an option. I'm happy to add options, features etc. to fix gaps in the
> current implementation.
FWIW I'd also appreciate to have an option to easily parallelize builds
without having to call make separately.

We're now at a point where it doesn't seem very exotic to have 12-16
cores in an affordable, portable 14" laptop[1], so IMHO it should be as
easy as possible to utilize those, as it does make things a lot faster.

Maybe it should even default to the number of available cores (i.e.
"nproc")? Though others might prefer using a single job by default like
make does as well, not sure.

Florian

[1] https://www.lenovo.com/us/en/laptops/thinkpad/thinkpad-t-series/ThinkPad-T14-AMD-G1/p/22TPT14T4A2

--
[hidden email] (Mail/XMPP) | https://www.qutebrowser.org 
       https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
       GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
             I love long mails! | https://email.is-not-s.ms/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Phil Thompson-5
In reply to this post by Florian Bruhin
On 16/09/2020 09:57, Florian Bruhin wrote:
> Hey,
>
> I also have a question I haven't seen in this thread yet: IIRC there
> were plans to rewrite the code generation part of SIP in Python. Is
> this
> going to be a part of SIP v6 as well, or is this for "somewhen later"?

That will be ongoing during the lifetime of v6 and will be complete on
the release of v7.

Phil
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Dmitry Shachnev
In reply to this post by Kovid Goyal
On Wed, Sep 16, 2020 at 08:59:58AM +0530, Kovid Goyal wrote:
> Thanks, Eli. --no-make looks like the missing piece. With it I can
> even parallelize the build.

That's what I use in Debian as well.

--
Dmitry Shachnev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Dmitry Shachnev
In reply to this post by Phil Thompson-5
On Tue, Sep 15, 2020 at 10:12:11PM +0100, Phil Thompson wrote:

> > 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.
>
> > 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.
Great! Thank you for confirming that.

So my updated plan will be building PyQt5 with the latest SIP, and letting
the applications choose between old SIP (v4) and new one (v5 which will be
replaced with v6 later).

--
Dmitry Shachnev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions about next versions of SIP

Phil Thompson-5
In reply to this post by Florian Bruhin
On 16/09/2020 10:04, Florian Bruhin wrote:

> On Wed, Sep 16, 2020 at 09:31:27AM +0100, Phil Thompson wrote:
>> On 16/09/2020 04:19, Kovid Goyal wrote:
>> > On Tue, Sep 15, 2020 at 10:46:30PM +0530, Kovid Goyal wrote:
>> > > Best I can come up with is to use sip-build and install manually
>> > > myself
>> >
>> > That's what I ended up doing. Another question, how do I get sip-build
>> > to use multiple CPU cores? With configure.py there was -j there doesnt
>> > seem
>> > to be any equivalent in sip-build. Makes building PyQt unnecessarily
>> > slow.
>>
>> You can run sip-build with --no-make and run make separately. Or I can
>> add
>> an option. I'm happy to add options, features etc. to fix gaps in the
>> current implementation.
>
> FWIW I'd also appreciate to have an option to easily parallelize builds
> without having to call make separately.
>
> We're now at a point where it doesn't seem very exotic to have 12-16
> cores in an affordable, portable 14" laptop[1], so IMHO it should be as
> easy as possible to utilize those, as it does make things a lot faster.
>
> Maybe it should even default to the number of available cores (i.e.
> "nproc")? Though others might prefer using a single job by default like
> make does as well, not sure.

I've added a --jobs option.

Phil
12