Default installation should use libevent plugin

10:11 < mnunberg> avsej: also. it's not using the libevent backend
10:11 <+avsej> it signs the repository during import
10:11 <+avsej> https://github.com/couchbaselabs/lcbpackage/blob/master/rakefiles/repositories.rake#L143
10:11 < mnunberg> cbc built from: libcouchbase 2.3.0 (rev. 7b11fe7e4f8f23f24861fe82287d7eb10de2c6b4) using libcouchbase: 2.3.0 (select)
10:12 <+avsej> did you install libcouchbase2-libevent?
10:12 < mnunberg> uhmm..
10:12 < mnunberg> i thought the default behavior was for it to pull in libevent
10:12 < mnunberg> no i didn't install it explicitly
10:12 <+avsej> there should be file like ubuntu/config/distributions
10:13 <+avsej> mnunberg, it won't install it implicitly either
10:13 < mnunberg> hrm, that's not good
10:13 <+avsej> so if you need libevent just install it
10:13 <+avsej> libcouchbase2-libevent
10:13 < mnunberg> but if that's hwo previous versions did it, then ok
10:13 < mnunberg> it doesn't matter to me now
10:13 <+avsej> it is documented http://www.couchbase.com/communities/c-client-library
10:14 < mnunberg> another thing i'd like to do in 3.0 is a blanket dependency on libevent. it's the most well tested and stable of our event loops
10:14 < mnunberg> if you don't want libevent, compile from source
10:17 <+avsej> what if people are using libevent1 in their libraries? they will end up having two versions in their app?
10:18 <+avsej> i don't see issue at all
10:18 <+avsej> it is always better to rely on the repository maintainer rather then us
10:18 <+avsej> are you sure we will push new libcouchbase for each new release of libevent?
10:18 < mnunberg> most people installing libcouchbase are using it as a dependency for ruby php python etc.
10:19 < mnunberg> so we should give the most optimal runtime defaults
10:19 <+avsej> right
10:19 <+avsej> in this case they won't use libcouchbase IO at all
10:19 <+avsej> this is why we have libcouchbase2-core package
10:19 <+avsej> without any dependencies and additional blobs
10:19 < mnunberg> not really. most folks are still using the default I/O plugin, whichever it is that ships
10:19 <+avsej> for ruby people just want libcouchbase
10:20 <+avsej> and for python they also have their own
10:20 < mnunberg> that's the "Most minimal packaging configuration", not "Most optimal runtime configuration"
10:20 < mnunberg> python optionally elts you use your own I/O but it's not the default
10:20 < mnunberg> for normal sycnrhonous operatin you want the fastest there is
10:20 < mnunberg> and that's what most use cases are
10:21 <+avsej> so you mean that select implementation is the slowest? it adds a little overhead, and we don't have c10k on the client
10:21 < mnunberg> avsej: it's also buggier
10:22 < mnunberg> 14
10:22 < mnunberg> err..
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/select/ | wc -l 14
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/libevent/ | wc -l 4
10:23 < mnunberg> mnunberg@mbp15 ~/Source/lcb-master $ git log 2.0.0..HEAD --pretty=oneline plugins/io/libev/ | wc -l 7
10:24 < mnunberg> on the other hand select is simpler to debug
10:24 < mnunberg> eh, i don't know
10:25 <+avsej> in any event people have easy what to substitute it, and so far select is good as minimal implementation
10:25 <+avsej> the recommended way to install libcouchbase is 'yum install libcouchbase-devel libcouchbase2-libevent'
10:26 <+avsej> so I don't see any issue
10:26 < mnunberg> that's not the most intuitive way of installing a package
10:26 < mnunberg> if my documentation says "I need dependency FOO" i'll go ahead and query my package manager and install "FOO"
10:26 < mnunberg> i'm not gonna jump to some other document telling me what to install
10:27 <+avsej> why not fix documentation then
10:27 < mnunberg> because people don't read documentation
10:27 < mnunberg> as a rule, people only read documentation enough to get them up and running
10:27 <+avsej> just recently i was compiling nginx with some module which has dependency on gd
10:27 <+avsej> and first thing I was tried is yum install libgd-devel which failed
10:28 <+avsej> the correct way was gd-devel
10:29 <+avsej> in any event libevent is not good enough as default for ruby and I against to have this as mandatory dependency
10:29 <+avsej> libevent doesn't allow to release GIL while it is doing IO
10:29 <+avsej> the ruby IO plugin does
10:30 <+avsej> you probably can rename the packages, but please leave ability to install libcouchbase2-core, i.e. without any plugins
10:30 < mnunberg> it's the default for python and php. i think the way i wanted this to begin with was a libcouchbase2 metapackage
10:30 < mnunberg> i.e. libcouchbase2 would install libcouchbase2 and libevent
10:31 < mnunberg> and for things that had "Special" requirements, they could use '-core'
10:31 <+avsej> why not remove libcouchbase2 package at all
10:31 < mnunberg> we don't have such a package afaict
10:31 <+avsej> and update docs to install libcouchbase2-libevent if they depend on it
10:32 <+avsej> right
10:32 <+avsej> no package no problem
10:32 < mnunberg> going back to my point
10:32 < mnunberg> people don't read docs
10:32 < mnunberg> especially if not installing libevent doesn't actually give any kind of error or issues until much later when it's in production
10:32 < mnunberg> and then it's like "Oh, we're crashing"
10:32 <+avsej> https://github.com/couchbase/libcouchbase/blob/master/packaging/deb/control#L39 remove this line
10:32 < mnunberg> so then we ask "Ok, tell me what I/O plugin you're using"
10:32 < mnunberg> "Oh, you're using select. You should use libevent"
10:32 <+avsej> or rather move it to libcouchbase2-libevent sectio
10:33 <+avsej> https://github.com/couchbase/libcouchbase/blob/master/packaging/deb/control#L12 after this one
10:33 < mnunberg> avsej: not this release. these are just plans for a 3.0 or whatever
10:33 < mnunberg> i'd rather not touch or change behavior
10:34 <+avsej> rpm also has equivalent https://github.com/couchbase/libcouchbase/blob/master/packaging/rpm/libcouchbase.spec.in#L34
10:34 <+avsej> i'm okay with solution which is about moving alias 'libcouchbase2' from 'libcouchbase2-core' to 'libcouchbase2-libevent'
10:34 <+avsej> totally agree with it
10:35 <+avsej> seems like the easiest solution
10:35 < mnunberg> avsej: yeah, we'll need to schedule it for next release, like .future
10:35 < mnunberg> let me do this on JIRA
10:35 <+avsej> could you copy this log there?
10:35 <+avsej> or extract the main idea
10:35 < mnunberg> ok