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

_______________________________________________
Geany mailing list
Geany@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany

_______________________________________________
Geany mailing list
Geany@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany