On Oct 31, 2012, at 23:28 , Alexander Shorin <[email protected]> wrote:
> Hi Jan. > > More detailed and explained question from IRC meeting. Thanks! > 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. Cheers Jan -- > 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 >> -- >>
