[Geany] Package and plugin management

Matthew Brush mbrush at xxxxx
Tue Jan 10 06:27:00 UTC 2012


On 01/09/2012 08:40 PM, Sayth wrote:
> I think it would be good to review it as an option. How does vim get around this issue to be platform agnostic?
>

I don't use VIM but IIRC it has some concept of "VIM scripts" and I 
think maybe also Python plugins.

Cheers,
Matthew Brush

> Sent from my iPhone
>
> On 10/01/2012, at 1:09 PM, Matthew Brush<mbrush at codebrainz.ca>  wrote:
>
>> On 01/09/2012 03:56 PM, Sayth Renshaw wrote:
>>> After noticing a recent discussion regarding packaging themes I got
>>> thinking(just a little, didn't hurt...much) and wondered if this could
>>> be managed better. Not just themes but plugins as a whole.
>>>
>>> The reason I raise this I have noticed recently several projects
>>> utilising 'independent' plugin management. Utilising github or rubygems
>>> to allow authors and users to create and share plugins and manage and
>>> track issues openly.
>>>
>>> For example I have found.
>>>
>>> Vim uses vundle: https://github.com/gmarik/vundle
>>> Once installed a user simply updates the vimrc with the github address.
>>>
>>> Bundle 'git://somegit address.hit'
>>>
>>> Then :BundleInstall
>>>
>>> All plugin functionailty is then available to the user.
>>> Similarly I found two other projects adopting a similar approach, redcar
>>> changed its entire plugin system for redcar 0.12 so that users now type
>>> /gem install redcar-plugin_name /to have the functionailty available.
>>> Another project Sublime Text has a function builtin(amongst) several if
>>> you open it I think ALT+P or something and select the package function
>>> it searches github for plugins to install(not real sure exactly how this
>>> happens).
>>>
>>> so I was just bringing this up because I thought the person previously
>>> who packaged themes for fedora has done a good job but his/her effort
>>> needs to be replicated for each platform/distribution, if utilising
>>> github we could do it once for every platform and distribution.
>>>
>>> Just a thought, it might invite/create more plugins being built for
>>> geany and reduce the workload of the core developers who can remove
>>> limited use functionailty to plugins and care more about the core.
>>>
>>
>> It's an interesting idea, I was actually thinking of doing this for GeanyPy plugins, since it's fairly trivial to do all of this in/with Python.
>>
>> The problem for the main plugins (Geany-Plugins, GeanyPy, etc.) is that they are all in C, and need to be compiled, and so have quite a few dependencies to compile which aren't needed otherwise. Even to do this in an automated way would be quite platform/distro/build environment specific.
>>
>> You could keep binaries in the repository, but then I think you'd still need a bunch of different binaries (re)built at each commit, at least one per architecture, and then probably a different one for each distro that isn't the same as others (like paths to libraries, datadirs, etc). And then Windows, and whatever else. On top of this, there'd also need to be a separate binary for each plugin built for each Geany version so that the API/ABI versions match up to what the user is running.
>>
>> Cheers,
>> Matthew Brush
>> _______________________________________________
>> Geany mailing list
>> Geany at uvena.de
>> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
> _______________________________________________
> Geany mailing list
> Geany at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany




More information about the Users mailing list