Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates
 209.85.214.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=gRHhClWEDcUrN+4O3u4CSD5GW5BZ9GqYYpL8iwSRT2i3k3cOp6JrtDIbJ9XmjJlvoH
         mOy2iw3Hkk1rjBMb+Sl40FD0BYm02UOKWJd6V+DEcSzCVi3mvnB56gn64QDwF/1BeRQs
         6HLSt2jsoCTBUma+WJcmRwK7H3daK33GOfrB0=
MIME-Version: 1.0
In-Reply-To: <AANLkTinjxrXteeG2zdGhengQy+-JoL+YxGPyrPsfN20Y@mail.gmail.com>
References: <AANLkTi=HFPKeHr9KOv0GFAjgOrWqg+tETMrNz9My=3WZ@mail.gmail.com>
	<AANLkTinjxrXteeG2zdGhengQy+-JoL+YxGPyrPsfN20Y@mail.gmail.com>
Date: Fri, 15 Oct 2010 07:50:36 +0200
Message-ID: <AANLkTi=8UaRv_A+gKbC8-izve3OpFZBFY7JYTw94SBNr@mail.gmail.com>
Subject: Re: Using rebar to install couchdb
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 14, 2010 at 8:54 PM, Paul Davis <paul.joseph.davis@gmail.com> w=
rote:
> 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 proposa=
l:
>
> etap:
>
> =A0 =A0Nick 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:
>
> =A0 =A0Should be renamed to just oauth. That erlang- prefix has bugged me
> fore entirely too long.
>
> mochiweb, ibrowse, oauth:
>
> =A0 =A0Refactored to use standard src, include, ebin, priv directories to
> be OTP compliant. This results in directories like
>
> =A0 =A0 =A0 =A0./src/$APP/ebin
> =A0 =A0 =A0 =A0./src/$APP/incldue
> =A0 =A0 =A0 =A0./src/$APP/priv
> =A0 =A0 =A0 =A0./src/$APP/src
>
> couchdb:
>
> =A0 =A0Each proposed app will be structured as described above. Proposed =
apps:
>
> =A0 =A0couch_core: The core Erlang modules for storing docs and managing
> "internal infrastructure"
> =A0 =A0couch_view: The view engine as well as the holder for managing OS =
processes.
> =A0 =A0couch_rep: couch_rep*.erl
> =A0 =A0couch_externals: couch_external*.erl
> =A0 =A0couch_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 a=
dam)

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=EEt