Can we send this upstream?

Probably, it should just be a matter of deb packaging but it won't solve the Flatpak issue I ran up against. I am not convinced libpeas-2 is the way to go - it provides a lot of stuff we don't need like loading JavaScript plugins which has to be included in the Flatpak (unless there are some compile options I haven't found yet). I am going to try to produce another PR removing libpeas altogether for comparison.

Libpeas may provide small advantages in code organization, but as far as I am aware the main point is to allow third-party plugins written in other languages and separately packaged in other projects to be used (they just need to be installed into the right directory).

Its not a problem, just unnecessary. Need to identify functional advantages of libpeas to justify the extra dependencies.

@danirabbit Will it be possible to ship libpeas-2 version 2.0.5 in elementary 8 if it is not in Ubuntu 24.04?

The main advantage of keeping the libpeas dependency for now, especially if we can lose the need for the .vapi, is the smaller diff. Even better if libpeas-2 can be absorbed in the elementary platform.

Hmm - as far as I can make out,, even Gnome is not using libpeas-2 for their gedit flatpak 😞

@leonardo-lemos Thanks! I forgot to check the CI file as everything worked locally.

@kaixoo Thanks for the offer. The limiting factor is getting reviews and re-reviews of existing (simpler, ready) PRs tbh. I guess people are focussed on finalizing the stable release of OS 8. I could mark this as ready for review if you like, otherwise I was waiting for the .vapi file to be included in the -dev package.

I've started a fork of Code that I can use myself at least that contains some of the more useful features that are not in the original.

@jeremypw Can you resolve the conflicts here, please? I'd like to take a look at this PR ;)