[Geany-Devel] Proxy Plugins Update
elextr at xxxxx
Fri Jul 11 23:35:05 UTC 2014
On 12 July 2014 09:25, Matthew Brush <mbrush at codebrainz.ca> wrote:
> On 14-07-11 01:25 PM, Thomas Martitz wrote:
>> Am 11.07.2014 22:03, schrieb Colomban Wendling:
>>> Le 07/07/2014 18:48, Thomas Martitz a écrit :
>>>> In my last post I've followed the approach of proxy plugins, aka pluxys.
>>>> This approach is based on geanypy and implements a plugin API for
>>>> plugins to act as proxy. I have mostly finished that (including an
>>>> trivial example pluxy), and ported geanypy to this framework. The result
>>>> is that with this approach I was successfully able to load python
>>>> plugins with the core, including access to the plugin API, to the extend
>>>> that geanypy allows plus keybindings via a new (experimental) API call.
>>>> I think this should cover almost everything you would want for python
>>>> Since with that work you can successfully load python plugins I consider
>>>> this approach workable.
>>>> Now that the pluxy approach is in the final stages I went onto toying
>>>> with libpeas.
>>>> There are three areas of problems with libpeas before we can adapt it,
>>>> two of which I could already solve in a fork.
>>> If using libpeas really requires having a modified version of it lying
>>> in our code, I'm not convinced it's a great idea.
>> It's because we require modifications to it for backwards compat, this
>> way we could maintain ABI and API stability across a transition to
>> libpeas. We can drop it from our source after the transition period
>> and/or convince upstream to accept rather geany-specific code (unlikely).
>> Another issue is that upstream libpeas tends to require recent glib/gtk
>> versions even when not justified. The fork would allow us to lower the
>> glib/gtk requirements.
> If they're not justified, then why not provide upstream with a patch that
> lowers them to minimum version required?
>> libpeas is tiny, and is not actively developed (one can consider the
>> project mostly done). So I don't think it's a big deal really. On the
>> other concept of libpeas does provide a lot of benefits so it's worth it
>> What alternatives can you propose?
As I understand it you only need to bundle peas to be able to add the
backward compatible loader?
If that is going to be for a limited deprecation period (say two
release periods after the peas version is released) then it is
reasonable to argue that the changes to libpeas are Geany specific,
for a limited period and not worth pushing upstream.
Although Fedora are well known to be strict on this, that is one of
their acceptable reasons.
> Not bundling it in the tree :)
> You haven't really given any good reasons why we need to fork libpeas that
> can't be solved by working with upstream to make the things you want to do
> possible (ex. exposing the needed headers/types). AFAIK some distros
> hate when apps bundle libs like this and might require at least that we
> tried to work with upstream before we can get exceptions about embedding
> current/active/readily-available system libraries in our tree.
> Alternatively, couldn't you do the Peas extensions completely separate from
> the existing loader code (as in my "peas" branch), and then make the plugin
> manager GUI homogeneous so that it's the same experience for plugin users?
> Without trying to munge our old loader together with the Peas loader, all of
> your problems would fall away, IIUC (or at least make a new different set of
> problems :)
> Matthew Brush
> : http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
> : https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
> Devel mailing list
> Devel at lists.geany.org
More information about the Devel