[Geany-Devel] Proxy Plugins Update

[Lex Trotman]

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
>>>> plugins.
>>>>
>>>> Since with that work you can successfully load python plugins I consider
>>>> this approach workable.
>>>
>>> Nice.
>>>
>>>> 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
>> IMO.
>>
>> What alternatives can you propose?
>>

Thomas,

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.

Cheers
Lex


>
> 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[1][2]
> 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 :)
>
> Cheers,
> Matthew Brush
>
> [1]: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
> [2]: https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel