Where to host plugins?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Where to host plugins?

wvengen
Administrator
Hi everyone,

I'm working the ability to have plugins that extend foodsoft [1]. A first step is moving the wiki to a plugin - see pull request #194 [1] (the wiki is a plugin enabled by default for backwards compatibility), which I plan to merge soon.

A simple practical question: where shall we host them?
  • keep them all in the foodsoft tree?
    • in lib/foodsoft_<plugin>, or rather lib/plugins/<plugin> or plugins/<plugin>?
      Didn't easily find prior art for this.
      This would also make sense as a location for a deployer to add plugins not part of foodsoft.
  • give each a separate github project in the foodcoops organisation?
  • create a github project foodsoft-plugins with a directory for each plugin? (cannot checkout one)
  • create a github project foodsoft-plugins with a branch for each plugin? (would that be clear enough?)

Best,
- Willem


[1] https://github.com/foodcoops/foodsoft/wiki/Plugins
[2] https://github.com/foodcoops/foodsoft/pull/194
Reply | Threaded
Open this post in threaded view
|

Re: Where to host plugins?

mathijs
Start out with the 1st option (a plugins folder) and then move to
another option when necessity arises. Some use cases:

- Perhaps some user wants to use foodsoft plugins in other applications
(highly unlikely).
- Could be that people running a newer or older release of the software
want to backport plugins. This requires API compatibility and requires
plugins to be well tested for this compatibility.

AFAIK, both of the above scenario's are not too realistic in the
forseeable feature - but I might have missed something.

wvengen [via foodsoft] schreef:
 > I'm working the ability to have plugins that extend foodsoft [1]. A
 > first step is moving the wiki to a plugin - see pull request #194 [1]
 > (the wiki is a plugin enabled by default for backwards compatibility),
 > which I plan to merge soon.
 >
 > A simple practical question: where shall we host them?
 >
 > * keep them all in the foodsoft tree?
 > o in lib/foodsoft_<plugin>, or rather lib/plugins/<plugin> or
 > plugins/<plugin>?
 > Didn't easily find prior art for this.
 > This would also make sense as a location for a deployer to add
 > plugins not part of foodsoft.
 > * give each a separate github project in the foodcoops organisation?
 > * create a github project foodsoft-plugins with a directory for each
 > plugin? (cannot checkout one)
 > * create a github project foodsoft-plugins with a branch for each
 > plugin? (would that be clear enough?)

Cheers,
Mathijs
Reply | Threaded
Open this post in threaded view
|

Re: Where to host plugins?

wvengen
Administrator
Good points.
Regarding API compatibility - and I hope to introduce tests for plugins
at some point.

The commit log of foodsoft would be cleaner if it wasn't cluttered with
commits for plugins. That's the most important reason I can think of not
wanting to have it in-tree. Does that make sense?

- Willem

On 07-11-13 18:37, mathijs [via foodsoft] wrote:

> Start out with the 1st option (a plugins folder) and then move to
> another option when necessity arises. Some use cases:
>
> - Perhaps some user wants to use foodsoft plugins in other applications
> (highly unlikely).
> - Could be that people running a newer or older release of the software
> want to backport plugins. This requires API compatibility and requires
> plugins to be well tested for this compatibility.
>
> AFAIK, both of the above scenario's are not too realistic in the
> forseeable feature - but I might have missed something.

Reply | Threaded
Open this post in threaded view
|

Re: Where to host plugins?

mathijs
A little but not worth the risk of breakage due to the version of plugins and code not being in sync. ^^

wvengen [via foodsoft] schreef:

>
> Good points.
> Regarding API compatibility - and I hope to introduce tests for plugins
> at some point.
>
> The commit log of foodsoft would be cleaner if it wasn't cluttered with
> commits for plugins. That's the most important reason I can think of not
> wanting to have it in-tree. Does that make sense?
>
> - Willem
>
> On 07-11-13 18:37, mathijs [via foodsoft] wrote:
>> Start out with the 1st option (a plugins folder) and then move to
>> another option when necessity arises. Some use cases:
>>
>> - Perhaps some user wants to use foodsoft plugins in other applications
>> (highly unlikely).
>> - Could be that people running a newer or older release of the software
>> want to backport plugins. This requires API compatibility and requires
>> plugins to be well tested for this compatibility.
>>
>> AFAIK, both of the above scenario's are not too realistic in the
>> forseeable feature - but I might have missed something.
>
>
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://foodsoft.51229.x6.nabble.com/Where-to-host-plugins-tp263p265.html
> To start a new topic under foodsoft-dev, email [hidden email]
> To unsubscribe from foodsoft-dev, visit