couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: CouchDB Plugins First Draft
Date Thu, 01 Nov 2012 11:56:17 GMT

On Oct 31, 2012, at 23:28 , Alexander Shorin <> wrote:

> Hi Jan.
> More detailed and explained question from IRC meeting.


> Why there is need to reinvent own package manager when most modern
> systems (even Windows) already has package manager?

There is no need to reinvent our own thing. I never made that claim.
I just sketched out what the end-user-interaction of a future plugin
system could look like.

Whatever technology we use to support that interaction is TBD.

* * *

You do bring up a number of good points that will need to be addressed
by whatever we end up doing, I’ll integrate them into the document and
solicit a review to make sure I didn’t miss anything.


> What problem tried to be solved?
> ------------------------------------------------------------
> Easy find, install and activate any CouchDB plugin in one-shot action,
> right? Following example from gist:
> $ cpm # couch plugin manager
> $ cpm search geocouch
> $ cpm install geocouch
> While it tries to simplify extending of CouchDB, it brings a lot of
> problems into system
> What problems cpm brings?
> -----------------------------------------------------
> 1. Dependencies.
> While any system package already able to resolve dependencies,
> conflicts, provide slots for different versions, cpm will need to
> reimplement this features. Geocouch isn't good example, next one is
> much better:
> $ cpm install couchdb-lucene # what about dependencies?
> I don't think (and hope it will not) that this command will install
> JRE and other java things into my system while I'm only expects this
> plugin. System package managers already know what need and which
> versions of to properly install lucene. Should this `cpm install`
> command only check for suitable environment before landing? Or may be
> cpm will know how to cooperate with system package managers to propose
> install required dependencies?
> 2. Namespace.
> Since CouchDB installs system-wide (most cases) should plugins be
> installed in same way? Or each user may have his own set of active
> plugins? But it looks like that only CouchDB admin may operate with
> plugins from Futon, so plugins have to live at least by path
> accessiable for couchdb user. So there couldn't be personalised
> plugins and npm system wouldn't work. So, cpm utility is only useful
> for root user which is already has access to system package manager.
> 3. BigCouch
> How plugins system proposed to be work after BigCouch merge? Would
> plugins be installed for all shards or only just for current one? Will
> cluster works right if some shards would have geocouch-1.0, some of
> them has geocouch-1.3 with breaking changes and for others it just
> missed?
> Why system package manager?
> ---------------------------------------------------------
> $ flaggie dev-db/couchdb +lucene # or echo "dev-db/couchdb lucene" >>
> /etc/portage/package.use
> $ emerge couchdb
> And we'd got CouchDB with couchdb-lucene plugin and handled all
> required dependencies. Now system takes care about packages
> consistency and we're always sure and accidental iceadtea uninstall
> would be passed silently since it have to break our couchdb-lucene
> extension.
> In same way other projects are already have implemented their
> "plugins" system: nginx, php. Yes, they have not plugins, but modules,
> but since they acts on system level there is no easy and secure way to
> let everyone enable/disable/install any thirdparty component and this
> way is the right one.
> Following RabbitMQ project, they ships with all main plugins on board
> - you need just to enable with through cli utility. If you need to
> install some third party plugin, just copy his directory to rabbits
> plugins one. But to be honest, RabbitMQ plugin manager tool doesn't
> tries to act as package manager: it only shows, enables and disables
> plugins, nothing more - that's why their approach works fine.
> So I've smoothly went from original question to set of other ones, but
> I suppose they are also interested to be answered since they are
> defined show cpm will work and handle plugins.
> P.S. Sorry for poorly mind dump style, 2:40 am there. I could try to
> explain something in other way if it wasn't clear enough...
> --
> ,,,^..^,,,
> On Mon, Oct 29, 2012 at 8:41 PM, Jan Lehnardt <> wrote:
>> Hey all,
>> during one of the past IRC Meetings I promised to write up
>> what I have in mind for a CouchDB Plugin System.
>> Here is my first draft:
>> This is very early stage, but I wanted to get the idea out
>> of the door. If anyone feels compelled to go into further
>> detail, or even implement some of this, more power to you!
>> Note: This is especially interesting for the non-Erlang
>> folks here that need an excuse to contribute :)
>> For the frontend, we’d need some mockups on how the Futon
>> interaction would work (that is regardless of the state
>> of Futon.Current and Futon.Next).
>> On the backend, you could start figuring out what the
>> registry could look like.
>> I’m looking forward to your feedback!
>> Cheers!
>> Jan
>> --

View raw message