couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: CouchDB Plugins First Draft
Date Wed, 31 Oct 2012 22:28:07 GMT
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?

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

Why system package manager?

$ flaggie dev-db/couchdb +lucene # or echo "dev-db/couchdb lucene" >>
$ 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

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