couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl McDade <>
Subject Re: (lack of) couchdb windows binaries
Date Thu, 01 Apr 2010 11:09:19 GMT
On Thu, Apr 1, 2010 at 11:54 AM, Mark Hammond <>wrote:

> On 1/04/2010 8:17 PM, Carl McDade wrote:
>> Hello,
>> I have been trying to use the Windows binaries of CouchDB but find that
>> the
>> installer creates issues that never get mentioned. The first concern and
>> one
>> that should be fixed is the distribution and linking of the Erlang
>> binaries
>> in the install. There should always be an option to use the Erlang
>> installation already on the machine. Hard linking the install to the
>> packaged Erlang binaries will almost guarantee non-use of the installer
>> and
>> a subsequent hunt for a way to compile CouchDB seperately.
> I'm afraid I need to disagree here - this issue has been raised so
> infrequently that I simply can't accept it as fact, especially given the
> number of "happy user" reports we have seen.  There is no evidence that the
> way we are packaging will "guarantee non-use of the installer" - do you have
> references to anyone else suggesting this is true for them or anyone else?
>  Indeed, I've seen so few reports of Windows users building from source that
> IMO it is patently false.

I am going from my experiences in working with Windows 2003 Server as a dev
platform. Maybe for a hobbyist or first time user there would be no problem.
But most Windows users frequently install Java, Ruby, PHP and Python in
seperate directories under Program Files or X:\[SOURCE] and use pointers in
configuration of the software that needs the sources. If the program in
question does not accept the sources already in place then it becomes a
point of frustration because multiple installs of the same source create

I guess there are two camps on this one. One being that the CouchDB windows
installer should provide a complete stack One-click install for development
environment  for Erlang, CouchDB and a Webserver, similar to Ruby One-Click,
Wampserver, Xammp etc. But it does not appear to do this yet. So while YAWS,
Ejabbard and other software would be running on single instance of Erlang.
guaranteeing use of single version, CouchDB might be running on a different

In my experiments there are collisions in running multiple versions of the
Erlang VM, Inets, Mochiweb and some binaries. YAWS for example simply
refuses to start while CouchDB (windows installation) is running. It becomes
chaotic and inconvenient to fix all the different instances. Windows users
love convenience and convention any disturbance in that and they typically
drop the software without blogging, bug reporting or emailing. There are
exceptions but not many.

That being said I would think that it's okay if the Erlang binaries in the
CouchDB environment can be used when installing YAWS or something similar.
This is the other camp where everything is encapsulated in the CouchDB
One-click and there is no need for anything else.

> I personally think our strategy is perfectly reasonable.  My experience
> with many Python based binary releases backs this up - eg, tools such as
> mercurial, bit-torrent, miro, spambayes, etc are distributed as a binary
> distribution on Windows and includes the full Python runtime - I'm not aware
> of any requests for such tools to allow for an already installed Python to
> be used with a binary.  Some people do choose to run from source for various
> reasons, but the vast majority - even those with Python already installed -
> are completely happy with the way the binaries work.
> Finally, providing an all-in-one installer significantly reduces the
> support burden for the project - there is no chance that user-installed bits
> and pieces will conflict with the install and cause erroneous error/support
> requests to be raised.
> I'm curious - why is this important to you?

Well you know that PHP is popular and the greater number of web developers
use Windows as their platform of choice. Since I see that Erlang and CouchDB
have a potentially bright futures in web work I would hate to see this
ruined with a reputation for not being Windows friendly. PostgreSQL suffered
from this for many years. But once a good Windows installer was released it
has seen significant improvement in popularity over the last three years. I
guess I want to see CouchDB grow without going through the same trials.

>  My second concern is the lack of user defined paths for the installation.
>> This also will cause many to uninstall and wait.
> The installer allows you to select the path you want to install into, and
> the normal couchdb mechanisms for overriding individual directories such as
> the data directory (ie, modifying the .ini files) works perfectly.  In this
> regard I don't see Windows as being at all different than other platforms.

On my last try the installer refused to accept any changes to the
x:\Program Files\ install directory. I will give it another try and report
it as a bug if confirmed.

> On the other hand though, I *do* see that being able to specify the data
> directory would be a nice feature - but not a critical one that will impact
> couchdb adoption on Windows.  Are there other directories you are concerned
> about?
> Maybe you just want this spelt out better in the installer readme?

Hmm, I don't think Windows users read those until something goes horribly
wrong ;) But yes, this would definatly help.

>  What should be remembered is that Windows users that are installing
>> CouchDB
>> want the same options that they would get when installing an RDMS. If
>> these
>> are not available then they will move on and never give any input so
>> quality
>> assurance is lost.
> As above, I see no evidence this is true for anyone other than yourself.  I
> understand some of these things might be nice to have, but I would need some
> evidence before I could accept they are a general concern shared by a
> significant number of potential users.
> Maybe you could take this to the -user list and see how many people agree
> this is critical rather than merely a nice optional feature?
>  Hope I did not step on any toes here :)
> Not at all - although I simply can't agree with your conclusions :)
> Cheers,
> Mark

Carl McDade
Webmaster - Drupal developer - PHP programmer
Stockholm Sweden

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message