Inquiry about API4 and new plugin packaging for Vapoursynth

[Vodes]

I'm wondering if y'all would be interested in updating the Vapoursynth plugin side of things to use api4, as api3 is slated to be removed this year after being deprecated for a couple of years.

And in the same breath; vapoursynth has adopted a python first mindset and plugins have been moving towards being installable by just doing for example pip install vapoursynth-bestsource.
For some more info:
https://www.vapoursynth.com/2026/03/26/new-packaging-and-install-methods-in-r74/
https://www.vapoursynth.com/doc/packaging.html

If there is some interest I could open a PR for both these things.
I forked it earlier and tried to keep it basically untouched for all other purposes so the maintenance burden would be minimal if any at all.
Disclaimer though: This is mostly sloppily copy pasted together from how vsfpng, bestsource and our ffms fork do it. My C and C build systems knowledge is surface level at best.

It currently only publishes to our custom index and not the main python registry.
Whether it be through a fork or the upstream, the goal is to be on the latter sooner or later. I just thought I'd ask before doing anything "official" in that direction.

Edit: I did decide to go ahead and publish it on the main index. If there's continued interest I would more than prefer to hand over the pypi project and get rid of my fork. You can see the updated workflow on my repo which just uses trusted publishing on the pypi side.

[Asd-g]

PR for API4 is welcome.

Do you use the meson or CMake for pypi?

[Vodes]

The CMake stuff is almost entirely untouched. I only added the api4 header discovery to it.
(But honestly did not test it, since meson really is the preferred path for this)

I added a build section to the vapoursynth readme to explain it as much as I can:
https://github.com/Vodes/L-SMASH-Works/tree/master/VapourSynth#build-meson

[Vodes]

I see there's no interest in a meson approach. Fwiw Cmake stuff can work too, see https://github.com/Jaded-Encoding-Thaumaturgy/vs-wheels/tree/master/atools for example.
And as mentioned above I definitely would like to hand over the pypi project if there's continued interest in getting it published as wheels.
I can also test any Linux x64 and mac arm builds myself if you need testing.

[msg7086]

Just want to clarify a bit on the meson thing. I don't have a strong opinion on which building system to use, however I saw many maintanences were done on CMake side, that's why I suggested to mark meson as a deprecated approach to avoid confusion. This project is mostly community driven, so if everyone agrees on moving to something different (or decide to move to meson from CMake) I have no problem with that all. Same goes to release approach, I'm fine with delivering through pip even though I don't use Python much.

[Vodes]

I assume I should interpret this as "patches welcome for the python build".
In that case, would anyone be opposed to the cross compile approach I had for the windows build? Probably a skill issue but I couldn't get the native windows build for the vendored ffmpeg working (on the CI anyways, I don't really have a windows machine to do this stuff on currently).
I'll give that another go but cross compilation was pretty foolproof.

Either way I can try setting up a cmake backed python build and get a PR going for that.

[Asd-g]

@Vodes, you can wait a bit with the patches for the python build. I will look at it so we can avoid double work.