My only thought is how well (if at all) it fits into an OTP shape.
On 31 October 2012 23:40, Robert Newson <[email protected]> wrote: > I quite like the rabbitmq approach (a lot like the apache httpd approach). > you can enable/disable/list plugins but the tool doesn't include the > downloading and managed repository bits, which is a huge rabbit hole (pun > intended). > > > > On 31 October 2012 22:28, Alexander Shorin <[email protected]> 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? >> >> >> 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 >> > -- >> > >> > >
