Re: A Plan: Remove pre-commit, jshint, code style requirements from couchdb-nano

[Jason Smith]

Hi, Robert. I agree with everything you said.

Furthermore, I would like to adopt the Fauxton style for the Nano project
(and I propose that it extends to all JavaScript under the CouchDB
umbrella).

As a first step, I will simply remove the tests from pre-commit hooks. In
the future, I would like to re-use or duplicate your CI tools for Nano. But
first thing's first! I want to fix a couple of bugs and ship a release.

On Wed, Sep 16, 2015 at 7:18 AM, Robert Kowalski <r...@kowalski.gd> wrote:

> Hey there,
>
> just as a report how we are doing it with Fauxton:
>
> the Fauxton project also has a styleguide in order to make reviews and
> reading code easier for everyone. At one point it turned out to reduce a
> lot of work for the reviewers if we test automatically for the coding style
> as part of our testsuite.
>
> We don't use commit hooks for it, but the CI will fail if the automatic
> coding style check and also the testsuite was not successful. the style
> check is runs before the unit tests run, which run before the integration
> tests. Red tests (that include tests for style) are a no-go for a merge in
> Fauxton.
>
> I don't think the checks must be enforced on a pre/post-commit-hook-level
> but somewhere they should notify the proposer of the change to make the
> live of the reviewer easier - in case you think code style is important for
> your project. I also want to not that some sub projects of CouchDB have no
> styleguide at all and that it can be a positive thing or a negative thing.
> Having one worked out well for Fauxton.
>
> I also think that deploying with a red CI might be OK in exceptional cases,
> but in these cases the deploying person should be aware why the test fails
> in 100%, and know the reasons why it is not fixable right now.
>
> In the recent past I have seen people saying they would know why the
> integration tests fails, delivering buggy releases.
>
> I think it is a small boundary and not everyone who says they know why the
> tests fail is 100% sure why they really fail (and deploys broken releases
> therefore). But I have worked with people that were so deep into the
> testsuites and the project they maintained in the past that they were able
> to predict that.
>
> In short I support whatever you decide for I just wanted to share my
> experiences, maybe it helps :)
>
> On Tue, Sep 15, 2015 at 2:54 PM, Jason Smith <jason.h.sm...@gmail.com>
> wrote:
>
> > Hi, Dale.
> >
> > On Tue, Sep 15, 2015 at 7:26 PM, Dale Harvey <d...@arandomurl.com>
> wrote:
> >
> > >
> > > I just wanted to clarify, are you speaking about removing as a
> > "pre-commit
> > > hook", or removing the requirements for those checks to pass before
> > > merging?
> > >
> >
> > I am speaking about removing the pre-commit hook only--the mechanical
> thing
> > that that runs automatically when one commits.
> >
> > The tests and checks would make brilliant push hooks, or perhaps Travis
> > tests for pull requests. However they are a bit much as a *commit* hook.
> >
> > A separate conversation: should the tests pass for merging. I would say:
> > yes if it's smart; no if it's dumb: they need not pass for merging, at
> > least not automatically, mechanically. The reason is that we should merge
> > pull requests liberally, accepting contributions from all, then commit on
> > top of those to correct for style. I won't have some sort of angry
> > Calvinist robot telling me I can't merge a pull request. (If we can be
> > clever, for example to require all tests pass for the master branch but
> not
> > feature branches, then yes I would love that.)
> >
>

Re: A Plan: Remove pre-commit, jshint, code style requirements from couchdb-nano

[Robert Kowalski]

Hey there,

just as a report how we are doing it with Fauxton:

the Fauxton project also has a styleguide in order to make reviews and
reading code easier for everyone. At one point it turned out to reduce a
lot of work for the reviewers if we test automatically for the coding style
as part of our testsuite.

We don't use commit hooks for it, but the CI will fail if the automatic
coding style check and also the testsuite was not successful. the style
check is runs before the unit tests run, which run before the integration
tests. Red tests (that include tests for style) are a no-go for a merge in
Fauxton.

I don't think the checks must be enforced on a pre/post-commit-hook-level
but somewhere they should notify the proposer of the change to make the
live of the reviewer easier - in case you think code style is important for
your project. I also want to not that some sub projects of CouchDB have no
styleguide at all and that it can be a positive thing or a negative thing.
Having one worked out well for Fauxton.

I also think that deploying with a red CI might be OK in exceptional cases,
but in these cases the deploying person should be aware why the test fails
in 100%, and know the reasons why it is not fixable right now.

In the recent past I have seen people saying they would know why the
integration tests fails, delivering buggy releases.

I think it is a small boundary and not everyone who says they know why the
tests fail is 100% sure why they really fail (and deploys broken releases
therefore). But I have worked with people that were so deep into the
testsuites and the project they maintained in the past that they were able
to predict that.

In short I support whatever you decide for I just wanted to share my
experiences, maybe it helps :)

On Tue, Sep 15, 2015 at 2:54 PM, Jason Smith <jason.h.sm...@gmail.com>
wrote:

> Hi, Dale.
>
> On Tue, Sep 15, 2015 at 7:26 PM, Dale Harvey <d...@arandomurl.com> wrote:
>
> >
> > I just wanted to clarify, are you speaking about removing as a
> "pre-commit
> > hook", or removing the requirements for those checks to pass before
> > merging?
> >
>
> I am speaking about removing the pre-commit hook only--the mechanical thing
> that that runs automatically when one commits.
>
> The tests and checks would make brilliant push hooks, or perhaps Travis
> tests for pull requests. However they are a bit much as a *commit* hook.
>
> A separate conversation: should the tests pass for merging. I would say:
> yes if it's smart; no if it's dumb: they need not pass for merging, at
> least not automatically, mechanically. The reason is that we should merge
> pull requests liberally, accepting contributions from all, then commit on
> top of those to correct for style. I won't have some sort of angry
> Calvinist robot telling me I can't merge a pull request. (If we can be
> clever, for example to require all tests pass for the master branch but not
> feature branches, then yes I would love that.)
>

A Plan: Remove pre-commit, jshint, code style requirements from couchdb-nano

[Jason Smith]

Hi, list!

I want to share my plan for preparing to work on couchdb-nano. Briefly, I
want to fix a thing or two in the project, but I think a more urgent change
is the pre-commit hooks enforcing coding style and test coverage.

The Nano project has several brilliant checks that it can do:
https://github.com/apache/couchdb-nano/blob/master/package.json#L50-L56

However, now that it is under the Apache CouchDB umbrella, I think these
checks are overkill. AFAIK, no other parts of the CouchDB project enforce a
particular style, certainly not as a condition to commit.

For example, here is a rejection by attempting to commit a single blank
line. https://gist.github.com/jhs/a198c75b4d06c72a5940 (TL;DR a huge test
suite runs, fails for some reason, and the commit is rejected).

A gem of the Nano project is that all of its http interactions are mocked.
You can run the entire test suite from a simple git clone (plus npm install
for dependencies). I would like to embrace that characteristic. If
contributors waiver on the style or test coverage, the maintainers can
shoulder that burden (for example, by committing to the contribution,
lowering the minimum coverage threshold, ha ha ha!).

Really, I am sending this email because it is a departure from the
dscape/nano philosophy. I think the world of Nano and its community. Nuno
is brilliant, and the Nano community is brilliant. I don't wan to--sort of
betray my gurus; but on the other hand, whoo boy, it's a bit much.

Re: A Plan: Remove pre-commit, jshint, code style requirements from couchdb-nano

[Dale Harvey]

Speaking from not a part of nano, but pouchdb has similiar checks and
requirements.

I just wanted to clarify, are you speaking about removing as a "pre-commit
hook", or removing the requirements for those checks to pass before merging?

The checks and tests existing and being enforced looks like a huge
positive, however if they are implemented via a pre-commit hook thats
blocking contributors even getting them up to a PR level so any issues can
be collaboratively fixed, that certainly seems like a problem.

On 15 September 2015 at 14:08, Jason Smith  wrote:

> Hi, list!
>
> I want to share my plan for preparing to work on couchdb-nano. Briefly, I
> want to fix a thing or two in the project, but I think a more urgent change
> is the pre-commit hooks enforcing coding style and test coverage.
>
> The Nano project has several brilliant checks that it can do:
> https://github.com/apache/couchdb-nano/blob/master/package.json#L50-L56
>
> However, now that it is under the Apache CouchDB umbrella, I think these
> checks are overkill. AFAIK, no other parts of the CouchDB project enforce a
> particular style, certainly not as a condition to commit.
>
> For example, here is a rejection by attempting to commit a single blank
> line. https://gist.github.com/jhs/a198c75b4d06c72a5940 (TL;DR a huge test
> suite runs, fails for some reason, and the commit is rejected).
>
> A gem of the Nano project is that all of its http interactions are mocked.
> You can run the entire test suite from a simple git clone (plus npm install
> for dependencies). I would like to embrace that characteristic. If
> contributors waiver on the style or test coverage, the maintainers can
> shoulder that burden (for example, by committing to the contribution,
> lowering the minimum coverage threshold, ha ha ha!).
>
> Really, I am sending this email because it is a departure from the
> dscape/nano philosophy. I think the world of Nano and its community. Nuno
> is brilliant, and the Nano community is brilliant. I don't wan to--sort of
> betray my gurus; but on the other hand, whoo boy, it's a bit much.
>

Re: A Plan: Remove pre-commit, jshint, code style requirements from couchdb-nano

[Johannes Jörg Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Jason,

I support your plan. I think one of the main reasons behind this
coverage contract [1] was to render the maintainer useless :) But
these pre commit hooks also have bugged me in the past.

Best
Schmidt

[1]: http://blog.yld.io/2014/11/12/nano6-and-the-coverage-contract/

On 15.09.2015 14:08, Jason Smith wrote:
> Hi, list!
> 
> I want to share my plan for preparing to work on couchdb-nano.
> Briefly, I want to fix a thing or two in the project, but I think a
> more urgent change is the pre-commit hooks enforcing coding style
> and test coverage.
> 
> The Nano project has several brilliant checks that it can do: 
> https://github.com/apache/couchdb-nano/blob/master/package.json#L50-L5
6
>
>  However, now that it is under the Apache CouchDB umbrella, I think
> these checks are overkill. AFAIK, no other parts of the CouchDB
> project enforce a particular style, certainly not as a condition to
> commit.
> 
> For example, here is a rejection by attempting to commit a single
> blank line. https://gist.github.com/jhs/a198c75b4d06c72a5940 (TL;DR
> a huge test suite runs, fails for some reason, and the commit is
> rejected).
> 
> A gem of the Nano project is that all of its http interactions are
> mocked. You can run the entire test suite from a simple git clone
> (plus npm install for dependencies). I would like to embrace that
> characteristic. If contributors waiver on the style or test
> coverage, the maintainers can shoulder that burden (for example, by
> committing to the contribution, lowering the minimum coverage
> threshold, ha ha ha!).
> 
> Really, I am sending this email because it is a departure from the 
> dscape/nano philosophy. I think the world of Nano and its
> community. Nuno is brilliant, and the Nano community is brilliant.
> I don't wan to--sort of betray my gurus; but on the other hand,
> whoo boy, it's a bit much.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV+A65AAoJED+W7gN+c0gcioMH/ROJ1RSoJZ3u0HUCouRybSo6
+TlUmEuErv9N4g5m4kXH6tXrr5HgvyvxiDZzp4OwdMDA6Q4Pba/kYci/TXz+shoH
+aoq/zkv/Z8H8dYNm7eQ1+b4I66czdvzawcxBypasqv3prY1akSFplpL5q8ZAawd
wLbhsZ7kORovRbs4U5ekFxER4Yf0xQP4ym34c11L19fHZd/nrI2OySBlOROJ/8m5
nTAMcH7pH5rVVPxJCNA6QG0UVh//w7GUfDe/+pZTl1Smno/FHXcXsd3mAAvdp1QH
kS6VXsjMeiWueDZFwVY15xKEwpAu8z26yv/vFqVrDjKqm5kkvMiSzONiULaTgZ8=
=iDMf
-END PGP SIGNATURE-

Re: A Plan: Remove pre-commit, jshint, code style requirements from couchdb-nano

[Jason Smith]

Hi, Dale.

On Tue, Sep 15, 2015 at 7:26 PM, Dale Harvey  wrote:

>
> I just wanted to clarify, are you speaking about removing as a "pre-commit
> hook", or removing the requirements for those checks to pass before
> merging?
>

I am speaking about removing the pre-commit hook only--the mechanical thing
that that runs automatically when one commits.

The tests and checks would make brilliant push hooks, or perhaps Travis
tests for pull requests. However they are a bit much as a *commit* hook.

A separate conversation: should the tests pass for merging. I would say:
yes if it's smart; no if it's dumb: they need not pass for merging, at
least not automatically, mechanically. The reason is that we should merge
pull requests liberally, accepting contributions from all, then commit on
top of those to correct for style. I won't have some sort of angry
Calvinist robot telling me I can't merge a pull request. (If we can be
clever, for example to require all tests pass for the master branch but not
feature branches, then yes I would love that.)

Re: Erlang API (was Re: code style)

[Benoit Chesneau]

On Mon, Jan 24, 2011 at 4:06 PM, Adam Kocoloski kocol...@apache.org wrote:
 On Jan 23, 2011, at 7:40 AM, Filipe David Manana wrote:

 On Sat, Jan 22, 2011 at 10:27 AM, Benoit Chesneau bchesn...@gmail.com 
 wrote:

 Imo the thing we could have in view, except this plugin support, is
 a simple api to call any part of couchdb we need. Something as simple
 as the HTTP api but for erlang.

  I'm thinking to have a couchbeam pure erlang api for example just for
 that. It would also help us to make new HTTP layer using webmachine
 for example or anything. fabric an hovercraft are also good
 inspiration. I'm pretty ready to do such thing. Does it worth a thread
 to discuss about it?

 You already have that with the new replicator. It brings a module
 named couch_api_wrap.erl. For now, it only has functions necessary
 for the replicator to operate both with local and remote databases.
 Nevertheless, it already covers a significant subset of the CouchDB API

 Yes, I think it's good to have a separate discussion on this one, but I'll go 
 ahead and toss my thoughts in here as well.  One of the things I quite like 
 about fabric.erl as opposed to couch_api_wrap.erl is that it minimizes the 
 use of records in the interface, e.g. it has converters to turn 
 client-supplied proplists into internal #changes_args and #view_query_args.  
 I also like that it accepts iodata() for most strings instead of requiring 
 the client to convert to binaries.  It saves some typing when interacting 
 with BigCouch from the shell.

+1 That's indeed really convenient as a client level.

 I think one big question for an Erlang API is whether it should require the 
 client to manually open and close the DB.  Fabric does not impose this 
 requirement, primarily because it doesn't make much sense in a BigCouch 
 cluster.  There are certainly advantages to having a DB handle open, but I 
 think many of those can be nullified by making it really cheap to open a DB.  
 My preference would be to make it optional, i.e. functions like update_docs 
 would have a clause that accepts a DbName (and a user context in the options) 
 in addition to one that accepts a #db.

At least I don't think we should test if a db exists or not when we
open a db like in couch_api_wrap, rather we should make it lazy and
crash only when we call a function using the db. So we minimize call.
I'm not sure about the impact of opening/closing a db right now but I
guess that if we monitor activity of the db process it should we the
case we let a db open?

- benoît

Erlang API (was Re: code style)

[Adam Kocoloski]

On Jan 23, 2011, at 7:40 AM, Filipe David Manana wrote:

 On Sat, Jan 22, 2011 at 10:27 AM, Benoit Chesneau bchesn...@gmail.com wrote:
 
 Imo the thing we could have in view, except this plugin support, is
 a simple api to call any part of couchdb we need. Something as simple
 as the HTTP api but for erlang.
 
  I'm thinking to have a couchbeam pure erlang api for example just for
 that. It would also help us to make new HTTP layer using webmachine
 for example or anything. fabric an hovercraft are also good
 inspiration. I'm pretty ready to do such thing. Does it worth a thread
 to discuss about it?
 
 You already have that with the new replicator. It brings a module
 named couch_api_wrap.erl. For now, it only has functions necessary
 for the replicator to operate both with local and remote databases.
 Nevertheless, it already covers a significant subset of the CouchDB API

Yes, I think it's good to have a separate discussion on this one, but I'll go 
ahead and toss my thoughts in here as well.  One of the things I quite like 
about fabric.erl as opposed to couch_api_wrap.erl is that it minimizes the use 
of records in the interface, e.g. it has converters to turn client-supplied 
proplists into internal #changes_args and #view_query_args.  I also like that 
it accepts iodata() for most strings instead of requiring the client to convert 
to binaries.  It saves some typing when interacting with BigCouch from the 
shell.

I think one big question for an Erlang API is whether it should require the 
client to manually open and close the DB.  Fabric does not impose this 
requirement, primarily because it doesn't make much sense in a BigCouch 
cluster.  There are certainly advantages to having a DB handle open, but I 
think many of those can be nullified by making it really cheap to open a DB.  
My preference would be to make it optional, i.e. functions like update_docs 
would have a clause that accepts a DbName (and a user context in the options) 
in addition to one that accepts a #db.

 
 
 - benoît
 
 
 
 
 -- 
 Filipe David Manana,
 fdman...@gmail.com, fdman...@apache.org
 
 Reasonable men adapt themselves to the world.
  Unreasonable men adapt the world to themselves.
  That's why all progress depends on unreasonable men.

Re: code style

[Filipe David Manana]

On Sat, Jan 22, 2011 at 10:27 AM, Benoit Chesneau bchesn...@gmail.com wrote:

 Imo the thing we could have in view, except this plugin support, is
 a simple api to call any part of couchdb we need. Something as simple
 as the HTTP api but for erlang.

  I'm thinking to have a couchbeam pure erlang api for example just for
 that. It would also help us to make new HTTP layer using webmachine
 for example or anything. fabric an hovercraft are also good
 inspiration. I'm pretty ready to do such thing. Does it worth a thread
 to discuss about it?

You already have that with the new replicator. It brings a module
named couch_api_wrap.erl. For now, it only has functions necessary
for the replicator to operate both with local and remote databases.
Nevertheless, it already covers a significant subset of the CouchDB API


 - benoît




-- 
Filipe David Manana,
fdman...@gmail.com, fdman...@apache.org

Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men.

Re: code style

[Benoit Chesneau]

On Thu, Jan 20, 2011 at 4:16 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
 I would like to see, before getting started on any of this, an RFC-style 
 document / wiki page that defines what a CouchDB plugins system looks like 
 that we agree on implementing.


 If this were any/most other languages I would totally agree. Except
 Erlang is kinda laissez-faire when it comes to calling bits of code.

 Regardless of what the plugin system ends up looking like, it'll
 basically be the same API that's used all over couchdb internals.
 It'll be self-automatically stable once we make it not suck.

 *After* there's a system in place that allows plugins to exist without
 a carnal knowledge of the code base I think it would be good to
 explicitly formalize what we support as a plugin but until then we
 just don't make any claim of supporting anything as we start adding
 and organizing in preparation.


Imo the thing we could have in view, except this plugin support, is
a simple api to call any part of couchdb we need. Something as simple
as the HTTP api but for erlang.

 I'm thinking to have a couchbeam pure erlang api for example just for
that. It would also help us to make new HTTP layer using webmachine
for example or anything. fabric an hovercraft are also good
inspiration. I'm pretty ready to do such thing. Does it worth a thread
to discuss about it?

- benoît

Re: code style

[Benoit Chesneau]

On Thu, Jan 20, 2011 at 2:57 PM, Adam Kocoloski kocol...@apache.org wrote:
 I'd go a little further.  I think CouchDB should have two include files:

 include/couch_db.hrl (I'd prefer couch.hrl but I think we might be stuck w/ 
 this)
 src/couch_int.hrl (name is not important)

 The first one would contain all record definitions needed to interact with 
 CouchDB from Erlang.  The second would contain macro definitions and records 
 that are not supposed to be exported.  Moving couch_db.hrl to include/ would 
 eventually allow other applications to point to couch_db.hrl using the 
 -include_lib directive instead of specifying the absolute path to the header. 
  Regards,

 Adam


+ 1 for such changes. While we are here we do the same for current
includes (waiting a better world) in ibrowse version etc and adding
include to erlopts when we build ?

- benoit

code style

[Benoit Chesneau]

Actually we are using ?b2l/?l2b and some other macros to make the code
shorter and ease our development. All these macros are in the main
include file couch_db.hrl used everywhere in the code.

Since this include will be likely used in CouchDB plugins created by
users, I would like to have these kind of macros separated in their
own include file. Something common in C world. The main reason is to
not pollute namesspacing in external plugins and let them import only
what they need, ie couchdb types/records.

What do you think about it? Also, not related but maybe it could be a
good practice to enforce the use of these macros in all the couchdb
codebase like suggest filippe.

Any thoughts ?

- benoît

Re: code style

[Benoit Chesneau]

On Thu, Jan 20, 2011 at 2:29 PM, Benoit Chesneau bchesn...@gmail.com wrote:

 codebase like suggest filippe.

s/filippe/filipe/ *kh*

Re: code style

[Adam Kocoloski]

I'd go a little further.  I think CouchDB should have two include files:

include/couch_db.hrl (I'd prefer couch.hrl but I think we might be stuck w/ 
this)
src/couch_int.hrl (name is not important)

The first one would contain all record definitions needed to interact with 
CouchDB from Erlang.  The second would contain macro definitions and records 
that are not supposed to be exported.  Moving couch_db.hrl to include/ would 
eventually allow other applications to point to couch_db.hrl using the 
-include_lib directive instead of specifying the absolute path to the header.  
Regards,

Adam

On Jan 20, 2011, at 8:29 AM, Benoit Chesneau wrote:

 Actually we are using ?b2l/?l2b and some other macros to make the code
 shorter and ease our development. All these macros are in the main
 include file couch_db.hrl used everywhere in the code.
 
 Since this include will be likely used in CouchDB plugins created by
 users, I would like to have these kind of macros separated in their
 own include file. Something common in C world. The main reason is to
 not pollute namesspacing in external plugins and let them import only
 what they need, ie couchdb types/records.
 
 What do you think about it? Also, not related but maybe it could be a
 good practice to enforce the use of these macros in all the couchdb
 codebase like suggest filippe.
 
 Any thoughts ?
 
 - benoît

Re: code style

[Robert Newson]

+1 on using ?l2b (and other macros) in all src/couchdb code. Any
lingering list_to_binary calls should be switched to the macro.

I think it's too early to split out the header file to allow use by
plugin authors. I'm in a minority, I think, by saying that without
some extra work, we are not ready to claim we support plugins.

I'd like to see, at minimum, a versioning scheme to declare
compatibility between couchdb and plugins (like browsers do, for
example). Beyond that, a statement on what parts of the interior of
couchdb are considered stable enough for plugin authors to depend on.

B.

On Thu, Jan 20, 2011 at 1:36 PM, Benoit Chesneau bchesn...@gmail.com wrote:
 On Thu, Jan 20, 2011 at 2:29 PM, Benoit Chesneau bchesn...@gmail.com wrote:

 codebase like suggest filippe.

 s/filippe/filipe/ *kh*

Re: code style

[Jan Lehnardt]

On 20 Jan 2011, at 14:57, Adam Kocoloski wrote:

 I'd go a little further.  I think CouchDB should have two include files:
 
 include/couch_db.hrl (I'd prefer couch.hrl but I think we might be stuck w/ 
 this)
 src/couch_int.hrl (name is not important)
 
 The first one would contain all record definitions needed to interact with 
 CouchDB from Erlang.  The second would contain macro definitions and records 
 that are not supposed to be exported.  Moving couch_db.hrl to include/ would 
 eventually allow other applications to point to couch_db.hrl using the 
 -include_lib directive instead of specifying the absolute path to the header. 
  Regards,

I like that approach best.

This is all part of a bigger discussion: what does a CouchDB plugin system look 
like. While technically, you can have plugins today, it is a fairly fragile 
endeavour.

The srvmv (tip hat Paul) will give us more foundations to make the technical 
part of this more solid. Fully fledged plugin support that I'd be comfortable 
supporting would also include a defined internal API for plugins to use that we 
give certain guarantees to not break. I know that's a bit off, but we should 
get there eventually.

I would like to see, before getting started on any of this, an RFC-style 
document / wiki page that defines what a CouchDB plugins system looks like that 
we agree on implementing.

Cheers
Jan
-- 


 
 Adam
 
 On Jan 20, 2011, at 8:29 AM, Benoit Chesneau wrote:
 
 Actually we are using ?b2l/?l2b and some other macros to make the code
 shorter and ease our development. All these macros are in the main
 include file couch_db.hrl used everywhere in the code.
 
 Since this include will be likely used in CouchDB plugins created by
 users, I would like to have these kind of macros separated in their
 own include file. Something common in C world. The main reason is to
 not pollute namesspacing in external plugins and let them import only
 what they need, ie couchdb types/records.
 
 What do you think about it? Also, not related but maybe it could be a
 good practice to enforce the use of these macros in all the couchdb
 codebase like suggest filippe.
 
 Any thoughts ?
 
 - benoît
 

Re: code style

[Robert Dionne]

On Jan 20, 2011, at 9:26 AM, Jan Lehnardt wrote:

 
 On 20 Jan 2011, at 14:57, Adam Kocoloski wrote:
 
 I'd go a little further.  I think CouchDB should have two include files:
 
 include/couch_db.hrl (I'd prefer couch.hrl but I think we might be stuck w/ 
 this)
 src/couch_int.hrl (name is not important)
 
 The first one would contain all record definitions needed to interact with 
 CouchDB from Erlang.  The second would contain macro definitions and records 
 that are not supposed to be exported.  Moving couch_db.hrl to include/ would 
 eventually allow other applications to point to couch_db.hrl using the 
 -include_lib directive instead of specifying the absolute path to the 
 header.  Regards,
 
 I like that approach best.
 
 This is all part of a bigger discussion: what does a CouchDB plugin system 
 look like. While technically, you can have plugins today, it is a fairly 
 fragile endeavour.
 
 The srvmv (tip hat Paul) will give us more foundations to make the technical 
 part of this more solid. Fully fledged plugin support that I'd be comfortable 
 supporting would also include a defined internal API for plugins to use that 
 we give certain guarantees to not break. I know that's a bit off, but we 
 should get there eventually.

+1


 
 I would like to see, before getting started on any of this, an RFC-style 
 document / wiki page that defines what a CouchDB plugins system looks like 
 that we agree on implementing.

+3


 
 Cheers
 Jan
 -- 
 
 
 
 Adam
 
 On Jan 20, 2011, at 8:29 AM, Benoit Chesneau wrote:
 
 Actually we are using ?b2l/?l2b and some other macros to make the code
 shorter and ease our development. All these macros are in the main
 include file couch_db.hrl used everywhere in the code.
 
 Since this include will be likely used in CouchDB plugins created by
 users, I would like to have these kind of macros separated in their
 own include file. Something common in C world. The main reason is to
 not pollute namesspacing in external plugins and let them import only
 what they need, ie couchdb types/records.
 
 What do you think about it? Also, not related but maybe it could be a
 good practice to enforce the use of these macros in all the couchdb
 codebase like suggest filippe.
 
 Any thoughts ?
 
 - benoît
 
 

Re: code style

[Paul Davis]

 I would like to see, before getting started on any of this, an RFC-style 
 document / wiki page that defines what a CouchDB plugins system looks like 
 that we agree on implementing.


If this were any/most other languages I would totally agree. Except
Erlang is kinda laissez-faire when it comes to calling bits of code.

Regardless of what the plugin system ends up looking like, it'll
basically be the same API that's used all over couchdb internals.
It'll be self-automatically stable once we make it not suck.

*After* there's a system in place that allows plugins to exist without
a carnal knowledge of the code base I think it would be good to
explicitly formalize what we support as a plugin but until then we
just don't make any claim of supporting anything as we start adding
and organizing in preparation.