Build with capnp 1.0 fails

[lgbaldoni]

/usr/include/kj/async.h:597:47: note: declared here
  597 | inline CaptureByMove<Func, Decay<MovedParam>> mvCapture(MovedParam&& param, Func&& func) {
      |                                               ^~~~~~~~~
capnp/lib/capnp.cpp: In function ‘PyObject* __pyx_f_5capnp_3lib_5capnp_12_CallContext_allow_cancellation(__pyx_obj_5capnp_3lib_5capnp__CallContext*, int)’:
capnp/lib/capnp.cpp:44255:28: error: ‘class capnp::CallContext<capnp::DynamicStruct, capnp::DynamicStruct>’ has no member named ‘allowCancellation’
44255 |     __pyx_v_self->thisptr->allowCancellation();
      |                            ^~~~~~~~~~~~~~~~~
capnp/lib/capnp.cpp: In function ‘PyObject* __pyx_f_5capnp_3lib_5capnp_12SchemaParser__parse_disk_file(__pyx_obj_5capnp_3lib_5capnp_SchemaParser*, PyObject*, PyObject*, PyObject*, int)’:
capnp/lib/capnp.cpp:76054:174: warning: ‘capnp::ParsedSchema capnp::SchemaParser::parseDiskFile(kj::StringPtr, kj::StringPtr, kj::ArrayPtr<const kj::StringPtr>) const’ is deprecated [-Wdeprecated-declarations]
76054 |   __pyx_t_1 = ((struct __pyx_vtabstruct_5capnp_3lib_5capnp__ParsedSchema *)__pyx_v_ret->__pyx_base.__pyx_vtab)->_init_child(__pyx_v_ret, __pyx_v_self->thisptr->parseDiskFile(__pyx_t_12, __pyx_t_15, __pyx_t_16)); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 3474, __pyx_L1_error)
      |                                                                                                                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from capnp/lib/capnp.cpp:832:
/usr/include/capnp/schema-parser.h:101:16: note: declared here
  101 |   ParsedSchema parseDiskFile(kj::StringPtr displayName, kj::StringPtr diskPath,
      |                ^~~~~~~~~~~~~
error: command '/usr/bin/gcc' failed with exit code 1

[haata]

Any more information? gcc version? OS version? Version of capnproto? Version of pycapnp?

[kentonv]

This is due to the breaking change in capnproto-c++ 1.0, mentioned in the blog post:

https://capnproto.org/news/2023-07-28-capnproto-1.0.html

The method allowCancellation() has been removed. Instead, you now use an annotation to opt into allowing cancellation.

pycapnp will have to remove its version of this method. I suppose a breaking change like this in Python is a bit trickier since it won't be caught at compile-time if an app is still using this. Perhaps the method should change to do nothing, and log a warning? Of course, it can be conditional on #if CAPNP_VERSION_MAJOR >= 1 so it does the right thing regardless of which capnp-c++ version is in use.

[lgbaldoni]

Any more information? gcc version?

13

OS version?

openSUSE Tumbleweed

Version of capnproto?

1.0.0

Version of pycapnp?

1.3.0

The method allowCancellation() has been removed. Instead, you now use an annotation to opt into allowing cancellation.

Indeed. I forgot to mention it. I assumed pycapnp and capnproto to have the same maintainers.

[kentonv]

Indeed. I forgot to mention it. I assumed pycapnp and capnproto to have the same maintainers.

Admittedly I (maintainer of capnproto-c++) probably should have coordinated better on this with @haata (maintainer of pycapnp) so that this was ready in advance. Didn't think of it for some reason. :/

[haata]

Sorry for being quiet, this is a bit of a crazy week for me, I'll try to see if I can work on it on the weekend.

[bbigras]

Any progress on this?

[haata]

Sorry for the delay. I've started to take a look at it this weekend.

I'm also realizing pip has been going through a lot of changes recently and a lot of the old options for building no longer work with recent pip versions. Basically --force-bundled-libcapnp will no longer work and I'll need to port all of the options to use something like this https://github.com/python-pillow/Pillow/pull/7171/files, sigh.

[haata]

Making some progress (thanks @tobiasah for getting me into gear and @LasseBlaauwbroek for all your hard work since the last release), just doing some final tests before pushing out a beta (found some annoying packaging bugs that have probably been there a while).

Current branch: https://github.com/haata/pycapnp/tree/capnp1.0

[tobiasah]

🎉 thanks a loot @haata

😁 I am still puzzled if there is an easy way to support versions < 1.0.0 ... But getting the version into the pyx file (e.g., through compile_time_env) before "cythonizing" is, as far as I can see, not possible because its determined later which version is used/bundled.

So the only way would be to do this outside of the pyx file.

BTW I do not need support for capnp > 1.0 ... but maybe someone relies on it?

[LasseBlaauwbroek]

Great @haata!

I'd also be in favor of supporting capnp < 1.0 for a while if possible. Many of the linux distros have not upgraded yet. Keeping some compatibility would be great. (Note that conda did upgrade capnp to 1.0.)

[LasseBlaauwbroek]

That being said, I'm probably fine with removing allowCancellation entirely. So if we can maintain backwards compatibility that way, it is okay for me.