[Geany] Package and plugin management

[Sayth Renshaw]

On Tue, Jan 10, 2012 at 5:27 PM, Matthew Brush <mbrush at codebrainz.ca> wrote:

> 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<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<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<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<https://lists.uvena.de/cgi-bin/mailman/listinfo/geany>
>


Well for the vim side I found this guide
http://items.sjbach.com/97/writing-a-vim-plugin basically you can create
using vims own vimscript, python, ruby or tcl. That's good for vim.

So in short it will be like wrangling monkeys to have a distributed plugin
architecture for geany.

Sayth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/users/attachments/20120110/6c013aa3/attachment.html>