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 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 <[email protected]> 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: > > https://gist.github.com/3974676 > > 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 > -- >
