couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Using rebar to install couchdb
Date Fri, 15 Oct 2010 05:50:36 GMT
On Thu, Oct 14, 2010 at 8:54 PM, Paul Davis <> wrote:
> So there's a couple issues at hand here which seem to be motivated by
> the desire to start using tools like rebar.
> Our current source tree is not compliant with some of the basic
> Erlang/OTP conventions. This is both bad technically and socially.
> Technically, it prevents us from easily integrating tools like rebar
> that would help advanced users with things like making Erlang reltools
> packages. Socially, it doesn't reflect well on us to members of the
> Erlang community that may have otherwise become contributors. All
> languages have a standard package layout and Erlang is no different.
> The current CouchDB Erlang app has grown considerably. There's been
> general consensus that we need to start splitting it up into smaller
> applications that encompass specific functionality. There's been a bit
> of effort in this direction, but its such a major change to source
> file location it needs to have a community consensus to really start
> working on seriously.
> I don't think we should focus directly on the issue of integrating
> rebar. It should definitely be a goal, but not at the cost of our
> current situation. Noah Slater has maintained an excellent build
> system for us as is shown by the number of people building CouchDB
> from source and the number of packages available. While I have argued
> with him on numerous occasions about details, I have come to the
> conclusion that it is not possible for him to be wrong. I personally
> attribute this to the fact that he's most likely an advanced robot
> from the future. That said, Noah has voiced concerns to various ideas
> and we should make sure that any of his concerns are fully addressed.
> We should attempt to make sure that any tool support doesn't morph
> into tool requirement. For instance, I think we should make sure that
> its possible to keep compiling CouchDB without rebar and not come to
> rely on it.
> While I'd be more than happy to start in on this and handle all of the
> build system refactoring to make this happen, I'm not going to start
> until there's a community consensus on what needs to be done. There
> are a couple paths that I could see us taking to make this happen. We
> could just make the current source tree be rebar compatible and figure
> out the build system to do the optional rebar build or we could also
> take this chance to split the source code into multiple applications.
> Personally, I'd prefer to take this opportunity to organize the code
> with multiple erlang apps.
> Too get the conversation rolling here's a first pass at a new app proposal:
> etap:
>    Nick Gerakines now releases etap as a single .erl file that can be
> dropped into the test directory. This app should be removed in favor
> of that method.
> erlang-oauth:
>    Should be renamed to just oauth. That erlang- prefix has bugged me
> fore entirely too long.
> mochiweb, ibrowse, oauth:
>    Refactored to use standard src, include, ebin, priv directories to
> be OTP compliant. This results in directories like
>        ./src/$APP/ebin
>        ./src/$APP/incldue
>        ./src/$APP/priv
>        ./src/$APP/src
> couchdb:
>    Each proposed app will be structured as described above. Proposed apps:
>    couch_core: The core Erlang modules for storing docs and managing
> "internal infrastructure"
>    couch_view: The view engine as well as the holder for managing OS processes.
>    couch_rep: couch_rep*.erl
>    couch_externals: couch_external*.erl
>    couch_httpd: couch_http*.erl
> At the bottom of this email I made an initial pass through the
> ./src/couchdb tree to classify file by file into the described apps.
> There are also some minor warts in this split. Things like the core
> couchdb classes currently require calling into the couch_view app and
> what not. Given the "interesting" call graph for CouchDb internals, I
> think we should avoid addressing this and aim to minimize the actual
> change to source file contents during this move. After modules have
> been moved we can then start on teasing out the various cyclic
> dependencies as necessary.
> Also, on a last note, seeing as this is a major change to the source
> tree (and ideally 0 change to source code) it might be a good idea to
> start this work just after we release 1.1.0.
> What do you guys think?
> Paul Davis
I'm +1 for this plan :

1) split couchdb in different apps.
2) Put rebar to handle "the low level details for the OTP apps"  (as said adam)

About 1 I asking myself if we shouldn't put rewrites and show in their
main apps "couchapp"

If we have a general consensus, I'm ready to start too.

- benoît

View raw message