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
Locked
