On 12 July 2014 09:25, Matthew Brush <mbr...@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@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel