CouchDB
  1. CouchDB
  2. COUCHDB-1012

Utility to help plugin developers manage paths

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2
    • Component/s: Build System
    • Labels:
      None
    • Skill Level:
      New Contributors Level (Easy)

      Description

      Developers may want to write plugins (like GeoCouch) for CouchDB. Many hooks in the configuration system allow loading arbitrary Erlang modules to handle various internal tasks, but currently there is no straightforward and portable way for developers of these plugins to discover the location of the CouchDB library files.

      Two options that have been proposed are to use pkg-config or install a separate script that could be invoked (e.g. as couch-config --erl-libs) to discover important CouchDB installation paths.

      As far as I know the loudest argument against pkg-config is lack of support for Windows.

        Activity

        Hide
        Paul Joseph Davis added a comment -

        Also against pkg-config is its not installed by default on OS X. Not sure about other BSD's either.

        Show
        Paul Joseph Davis added a comment - Also against pkg-config is its not installed by default on OS X. Not sure about other BSD's either.
        Hide
        Benoit Chesneau added a comment -

        neither is erlang We could make it a requirements for couchdb install.

        pkg-config is now installed by default on openbsd, not sure for other but I think it's now coming with xorg installation and in otther cases is easily installable via the package manager. ON OSX it's easily installable via homebrew, macports and fink.

        But, since we need to be multiplatform, maybe having a tiny script would do the trick better? One advantage of pkg-config is that's it can be now handle in autotools.

        Some links:
        http://lists.freedesktop.org/archives/pkg-config/2007-August/000219.html
        http://stackoverflow.com/questions/2164089/using-pkg-config-with-autotools
        http://www.flameeyes.eu/autotools-mythbuster/pkgconfig/index.html

        Also pkg-config is a common tool across platforms.

        Show
        Benoit Chesneau added a comment - neither is erlang We could make it a requirements for couchdb install. pkg-config is now installed by default on openbsd, not sure for other but I think it's now coming with xorg installation and in otther cases is easily installable via the package manager. ON OSX it's easily installable via homebrew, macports and fink. But, since we need to be multiplatform, maybe having a tiny script would do the trick better? One advantage of pkg-config is that's it can be now handle in autotools. Some links: http://lists.freedesktop.org/archives/pkg-config/2007-August/000219.html http://stackoverflow.com/questions/2164089/using-pkg-config-with-autotools http://www.flameeyes.eu/autotools-mythbuster/pkgconfig/index.html Also pkg-config is a common tool across platforms.
        Hide
        Randall Leeds added a comment -

        Apparently, "pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows." [1] This makes me favor using it rather than re-inventing the wheel.

        My feeling is that any OS X or Windows user who's installing CouchDB from source is already jumping through some dependency hoops. It's a trivial thing to add a dependency on pkg-config to the homebrew recipe for CouchDB. I've never built CouchDB on Windows, but isn't it done through MingW or something? If that's so, then it's not hard for these people to install pkg-config once as well (they might even already have it).

        We can make our own little script, but it just seems silly to me. Seems like we're polluting people's PATH with another Couch-related executable when a common, portable tool for doing this task already exists. I'm all for minimizing dependencies, but there's a limit and there's a reason why dependencies exist.

        If no one objects I'll try to write the patch.

        [1] http://pkg-config.freedesktop.org/wiki/

        Show
        Randall Leeds added a comment - Apparently, "pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows." [1] This makes me favor using it rather than re-inventing the wheel. My feeling is that any OS X or Windows user who's installing CouchDB from source is already jumping through some dependency hoops. It's a trivial thing to add a dependency on pkg-config to the homebrew recipe for CouchDB. I've never built CouchDB on Windows, but isn't it done through MingW or something? If that's so, then it's not hard for these people to install pkg-config once as well (they might even already have it). We can make our own little script, but it just seems silly to me. Seems like we're polluting people's PATH with another Couch-related executable when a common, portable tool for doing this task already exists. I'm all for minimizing dependencies, but there's a limit and there's a reason why dependencies exist. If no one objects I'll try to write the patch. [1] http://pkg-config.freedesktop.org/wiki/
        Hide
        Benoit Chesneau added a comment -

        i'm +1 for that.

        Show
        Benoit Chesneau added a comment - i'm +1 for that.
        Hide
        Klaus Trainer added a comment -

        Sounds good. I'm +1 for that, too.

        Show
        Klaus Trainer added a comment - Sounds good. I'm +1 for that, too.
        Hide
        Randall Leeds added a comment -

        Patch. I'm not super comfortable with autotools or conventions that may apply here, so please enlighten if you have feedback.

        `pkg-config --libs couchdb` - the flags to pass to erl in order to add all the couchdb apps to your erlang code path (e.g. "/usr/local/lib/couchdb/erlang/lib")

        `pkg-config --variable=libdir couchdb` - the raw directory, useful for installing your plugin where couch can find it. same as above but without the "-pa" switch.

        `pkg-config --cflags couchdb` a -I/path/to/couchdb-1.x/include` - passed to erlc to find couch_db.hrl

        Show
        Randall Leeds added a comment - Patch. I'm not super comfortable with autotools or conventions that may apply here, so please enlighten if you have feedback. `pkg-config --libs couchdb` - the flags to pass to erl in order to add all the couchdb apps to your erlang code path (e.g. "/usr/local/lib/couchdb/erlang/lib") `pkg-config --variable=libdir couchdb` - the raw directory, useful for installing your plugin where couch can find it. same as above but without the "-pa" switch. `pkg-config --cflags couchdb` a -I/path/to/couchdb-1.x/include` - passed to erlc to find couch_db.hrl
        Hide
        Paul Joseph Davis added a comment -

        Looks pretty good. I would probably try and avoid the double replace that we use in other places since we don't really need it.

        Show
        Paul Joseph Davis added a comment - Looks pretty good. I would probably try and avoid the double replace that we use in other places since we don't really need it.
        Hide
        Randall Leeds added a comment -

        You're right, Paul. No double substitution needed.
        I'm curious if anyone can build against this. If there's something I should do different to make integration with other tools, and especially rebar (which I'm not too familiar with), smoother please let me know.

        I don't know any projects that install pkg-config files for erlang, so it's sort of up to us to define what the useful variables are.

        Right now I've got `pkg-config --cflags couchdb` giving:
        -I/usr/local/lib/couchdb/erlang/lib/couch-1.2.0af9ee604-git

        and `pkg-config --libs couchdb` giving:
        -pa /usr/local/lib/couchdb/erlang/lib

        which are flags suitable for passing to erlc (the first two) and erl (just the --libs). However, if it's easier to just give the directories without the flags, for example for an install command to the place files in the couchdb code path, maybe that's better? It might be less confusing to just ignore the standard --cflags and --libs and use --variable=code_path and --variable=include_dir or something. Though, to be honest, --cflags doesn't bother to me toooo much (it's erl c after all...), but I digress.

        Feedback appreciated.

        Show
        Randall Leeds added a comment - You're right, Paul. No double substitution needed. I'm curious if anyone can build against this. If there's something I should do different to make integration with other tools, and especially rebar (which I'm not too familiar with), smoother please let me know. I don't know any projects that install pkg-config files for erlang, so it's sort of up to us to define what the useful variables are. Right now I've got `pkg-config --cflags couchdb` giving: -I/usr/local/lib/couchdb/erlang/lib/couch-1.2.0af9ee604-git and `pkg-config --libs couchdb` giving: -pa /usr/local/lib/couchdb/erlang/lib which are flags suitable for passing to erlc (the first two) and erl (just the --libs). However, if it's easier to just give the directories without the flags, for example for an install command to the place files in the couchdb code path, maybe that's better? It might be less confusing to just ignore the standard --cflags and --libs and use --variable=code_path and --variable=include_dir or something. Though, to be honest, --cflags doesn't bother to me toooo much (it's erl c after all...), but I digress. Feedback appreciated.
        Hide
        Andrew Tunnell-Jones added a comment -

        As far as I'm aware the only method of giving rebar additional include paths is to hardcode them in rebar.config with something like {erl_opts, [

        {i, "Path"}

        ]}. Due to this I think the least friction for integrating with rebar would be an option to get the path flag free so something like this can be dropped in rebar.config:

        {pre_hooks, [

        {clean, "rm include/couch_helper.hrl"}

        ,

        {compile, "echo -include\\(\"`pkg-config whatever`include/couchdb.hrl\"\\). > include/couch_helper.hrl"}

        ]}.

        +1 on having a flag-free path to the lib dir for install commands. An option to get the path to local.d could be useful too.

        Show
        Andrew Tunnell-Jones added a comment - As far as I'm aware the only method of giving rebar additional include paths is to hardcode them in rebar.config with something like {erl_opts, [ {i, "Path"} ]}. Due to this I think the least friction for integrating with rebar would be an option to get the path flag free so something like this can be dropped in rebar.config: {pre_hooks, [ {clean, "rm include/couch_helper.hrl"} , {compile, "echo -include\\(\"`pkg-config whatever`include/couchdb.hrl\"\\). > include/couch_helper.hrl"} ]}. +1 on having a flag-free path to the lib dir for install commands. An option to get the path to local.d could be useful too.
        Hide
        Benoit Chesneau added a comment - - edited

        Following our last discussion on IRC, find attached apatch that provide the new couch-config command to couchdb. This is a full shell script built during installation.

        Usage:

        $ ./bin/couch-config
        Usage: couch-config [OPTION]

        The couch-config command runs the Apache CouchDB configuration helper
        script.

        Options:

        --incdir Print path to include dir
        --libdir Print path to lib dir
        --ebindir Print path to ebin dir
        --privdir Print path to priv dir
        --bindir Print Path to the couchdb binary
        --confdir Print Path to the configuration dir
        --dbdir Print path to database dir
        --viewdir Print path to view index dir
        --urifile Print path to uri file
        --logfile Print path to log file
        --version Print version of couch-config
        -? Print usage

        Thoughts ?

        Show
        Benoit Chesneau added a comment - - edited Following our last discussion on IRC, find attached apatch that provide the new couch-config command to couchdb. This is a full shell script built during installation. Usage: $ ./bin/couch-config Usage: couch-config [OPTION] The couch-config command runs the Apache CouchDB configuration helper script. Options: --incdir Print path to include dir --libdir Print path to lib dir --ebindir Print path to ebin dir --privdir Print path to priv dir --bindir Print Path to the couchdb binary --confdir Print Path to the configuration dir --dbdir Print path to database dir --viewdir Print path to view index dir --urifile Print path to uri file --logfile Print path to log file --version Print version of couch-config -? Print usage Thoughts ?
        Hide
        Benoit Chesneau added a comment -

        new version of the patch fixing couch-config_dev.

        Show
        Benoit Chesneau added a comment - new version of the patch fixing couch-config_dev.
        Hide
        Jan Lehnardt added a comment -

        Just curious, what prompted the move from pkg-config to a custom script?

        Show
        Jan Lehnardt added a comment - Just curious, what prompted the move from pkg-config to a custom script?
        Hide
        Randall Leeds added a comment -

        Just the idea that it wouldn't require anyone using it to have pkg-config installed since it's not default available on some systems. It's widely available and easily installed, but not default. It's also a common pattern.

        In this way I suppose it's less friction in the worst case, and that seems like a good thing. If we want to be super nice we could also include a couch.m4 (omg how do you write those???).

        Show
        Randall Leeds added a comment - Just the idea that it wouldn't require anyone using it to have pkg-config installed since it's not default available on some systems. It's widely available and easily installed, but not default. It's also a common pattern. In this way I suppose it's less friction in the worst case, and that seems like a good thing. If we want to be super nice we could also include a couch.m4 (omg how do you write those???).
        Hide
        Noah Slater added a comment -

        I can help with M4 work.

        Show
        Noah Slater added a comment - I can help with M4 work.
        Hide
        Benoit Chesneau added a comment -

        most of multi-platforms programs provide both (pkg-config and their own config stuff) sicne pkg-config isn't installed by default on some platforms. Do you think it could be a problem to have both too with couchdb?

        Also what is the status of this ticket? What *actions* should we do to close it in near future?

        Show
        Benoit Chesneau added a comment - most of multi-platforms programs provide both (pkg-config and their own config stuff) sicne pkg-config isn't installed by default on some platforms. Do you think it could be a problem to have both too with couchdb? Also what is the status of this ticket? What * actions * should we do to close it in near future?
        Hide
        Noah Slater added a comment -

        Making our own script would be super trivial. If we go down that route, there's no point in also using pkg-config.

        Show
        Noah Slater added a comment - Making our own script would be super trivial. If we go down that route, there's no point in also using pkg-config.
        Hide
        Benoit Chesneau added a comment -

        the script is already done and attached to this patch. So what are we waiting for?

        Show
        Benoit Chesneau added a comment - the script is already done and attached to this patch. So what are we waiting for?
        Hide
        Paul Joseph Davis added a comment -

        Looking at both of these, I quite prefer the couch-config path over the pkg-config. couch-config offers a lot more settings and the patch is a lot more sane. I don't see why the pkg-config script is introducing new top level directories into the build system and so on.

        Only minor thing, the couch-config script uses -? for to display usage. I've not seen ? used for usage info since DOS, that's not some sort of shell script standard I've never seen is it? Even if it is, -h and --help should be supported as well.

        Other than that, I'd like to have Noah glance at that shell script as well. It looks pretty straight forward to me but he's the shell script portability expert.

        Other than that, I'd say it looks good to ship.

        Show
        Paul Joseph Davis added a comment - Looking at both of these, I quite prefer the couch-config path over the pkg-config. couch-config offers a lot more settings and the patch is a lot more sane. I don't see why the pkg-config script is introducing new top level directories into the build system and so on. Only minor thing, the couch-config script uses -? for to display usage. I've not seen ? used for usage info since DOS, that's not some sort of shell script standard I've never seen is it? Even if it is, -h and --help should be supported as well. Other than that, I'd like to have Noah glance at that shell script as well. It looks pretty straight forward to me but he's the shell script portability expert. Other than that, I'd say it looks good to ship.
        Hide
        Noah Slater added a comment -

        Oh, I had missed the patch.

        Comments:

        Please rename the script to couchenv.

        Please change the help output to be more helpful:

        The $basename command runs the %package_name% environment tool.

        When %package_name% is installed, certain environment variables are set.

        This script will display the current values of those variables.

        The exit status is 0 for success or 1 for failure.

        Please support --V, --version for printing version information.

        Please support -h, --help for printing help information.

        Please remove the -? option.

        Please make the wording of the help output start with:

        -h display a short help message and exit
        -V display version information and exit

        This is essential to main consistency between the output of the scripts we ship.

        Please change the wording of the help output the match this.

        As an example:

        --logfile Display log file path

        Please change the flags to mirror the variable name precisely:

        --couchlibdir
        --couchincludedir
        --couchebindir
        --dbdir
        --viewdir
        --couchprivlibdir
        --bindir
        --confdir
        --urifile
        --logfile

        Please add the new script to the dist_man1_MANS variable so that we build a man page for it.

        Please check that the new -h, -V output produces a sensible looking man page.

        Compare this with the man page for the couched command.

        I would recommend keeping with the variable names as they exist:

        So from this:

        +dbdir="%localstatelibdir%"

        To this:

        +localstatelibdir="%localstatelibdir%"

        As with the help output, it might seem like shortening them helps. I would argue that given sufficient knowledge of either CouchDB or Autotools, the originals make more sense. I know what the localstatelibdir is, because I have worked with that variable so much. The same is not necessarily true for dbdir. We should keep with the existing values throughout the code and our external interfaces to that code.

        Other than that, this is exactly how I would have implemented it.

        Show
        Noah Slater added a comment - Oh, I had missed the patch. Comments: Please rename the script to couchenv. Please change the help output to be more helpful: The $basename command runs the %package_name% environment tool. When %package_name% is installed, certain environment variables are set. This script will display the current values of those variables. The exit status is 0 for success or 1 for failure. Please support --V, --version for printing version information. Please support -h, --help for printing help information. Please remove the -? option. Please make the wording of the help output start with: -h display a short help message and exit -V display version information and exit This is essential to main consistency between the output of the scripts we ship. Please change the wording of the help output the match this. As an example: --logfile Display log file path Please change the flags to mirror the variable name precisely: --couchlibdir --couchincludedir --couchebindir --dbdir --viewdir --couchprivlibdir --bindir --confdir --urifile --logfile Please add the new script to the dist_man1_MANS variable so that we build a man page for it. Please check that the new -h, -V output produces a sensible looking man page. Compare this with the man page for the couched command. I would recommend keeping with the variable names as they exist: So from this: +dbdir="%localstatelibdir%" To this: +localstatelibdir="%localstatelibdir%" As with the help output, it might seem like shortening them helps. I would argue that given sufficient knowledge of either CouchDB or Autotools, the originals make more sense. I know what the localstatelibdir is, because I have worked with that variable so much. The same is not necessarily true for dbdir. We should keep with the existing values throughout the code and our external interfaces to that code. Other than that, this is exactly how I would have implemented it.
        Hide
        Noah Slater added a comment -

        That example should read:

        --logfile display logfile and exit

        Additionally, remove this:

        +urifile="%localstaterundir%/couch.uri"
        +logfile="%localstatelogdir%/couch.log"

        And instead have:

        +localstaterundir="%localstaterundir%"

        And then use this for the help output:

        --localstaterundir display localstaterundir and exit

        Show
        Noah Slater added a comment - That example should read: --logfile display logfile and exit Additionally, remove this: +urifile="%localstaterundir%/couch.uri" +logfile="%localstatelogdir%/couch.log" And instead have: +localstaterundir="%localstaterundir%" And then use this for the help output: --localstaterundir display localstaterundir and exit
        Hide
        Paul Joseph Davis added a comment -

        I think Noah's got a good point on accessing the original variables but we should keep the aliases. For people not versed in internals or the build system "localstatelibdir" is about as WTF as possible compared to dbdir. I would say maybe list the "user friendly" versions first, then the build system names second (though keeping -V and -h first).

        I'd disagree on changing the name to couchenv though. In my experience its a pretty consistent pattern for these scripts to be named $projectname-config. Changing it seems like it'll just be more WTF fodder.

        Show
        Paul Joseph Davis added a comment - I think Noah's got a good point on accessing the original variables but we should keep the aliases. For people not versed in internals or the build system "localstatelibdir" is about as WTF as possible compared to dbdir. I would say maybe list the "user friendly" versions first, then the build system names second (though keeping -V and -h first). I'd disagree on changing the name to couchenv though. In my experience its a pretty consistent pattern for these scripts to be named $projectname-config. Changing it seems like it'll just be more WTF fodder.
        Hide
        Noah Slater added a comment -

        Providing aliases for these environment variables is just going to muddy the water and potentially confuse people more. If you look at the output. The values here should precisely match the output from ./configure --help, which I did not think of checking before. Let me check that right now, as I write this very sentence.

        This is the output:

        Fine tuning of the installation directories:
        --bindir=DIR user executables [EPREFIX/bin]
        --sbindir=DIR system admin executables [EPREFIX/sbin]
        --libexecdir=DIR program executables [EPREFIX/libexec]
        --sysconfdir=DIR read-only single-machine data [PREFIX/etc]
        --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
        --localstatedir=DIR modifiable single-machine data [PREFIX/var]
        --libdir=DIR object code libraries [EPREFIX/lib]
        --includedir=DIR C header files [PREFIX/include]
        --oldincludedir=DIR C header files for non-gcc [/usr/include]
        --datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
        --datadir=DIR read-only architecture-independent data [DATAROOTDIR]
        --infodir=DIR info documentation [DATAROOTDIR/info]
        --localedir=DIR locale-dependent data [DATAROOTDIR/locale]
        --mandir=DIR man documentation [DATAROOTDIR/man]
        --docdir=DIR documentation root [DATAROOTDIR/doc/apache-couchdb]
        --htmldir=DIR html documentation [DOCDIR]
        --dvidir=DIR dvi documentation [DOCDIR]
        --pdfdir=DIR pdf documentation [DOCDIR]
        --psdir=DIR ps documentation [DOCDIR]

        I contend that the output of this script should be:

        --bindir user executables [EPREFIX/bin]
        --sbindir system admin executables [EPREFIX/sbin]
        --libexecdir program executables [EPREFIX/libexec]
        --sysconfdir read-only single-machine data [PREFIX/etc]
        --sharedstatedir modifiable architecture-independent data [PREFIX/com]
        --localstatedir modifiable single-machine data [PREFIX/var]
        --libdir object code libraries [EPREFIX/lib]
        --includedir C header files [PREFIX/include]
        --oldincludedir C header files for non-gcc [/usr/include]
        --datarootdir read-only arch.-independent data root [PREFIX/share]
        --datadir read-only architecture-independent data [DATAROOTDIR]
        --infodir info documentation [DATAROOTDIR/info]
        --localedir locale-dependent data [DATAROOTDIR/locale]
        --mandir man documentation [DATAROOTDIR/man]
        --docdir documentation root [DATAROOTDIR/doc/apache-couchdb]
        --htmldir html documentation [DOCDIR]
        --dvidir dvi documentation [DOCDIR]
        --pdfdir pdf documentation [DOCDIR]
        --psdir ps documentation [DOCDIR]

        I would also update the help description to read:

        The $basename command runs the %package_name% environment tool.

        When %package_name% is installed, certain environment variables are set.

        This script will display the current values of those variables.

        See the %package_name% ./configure --help output for more information.

        The exit status is 0 for success or 1 for failure.

        Show
        Noah Slater added a comment - Providing aliases for these environment variables is just going to muddy the water and potentially confuse people more. If you look at the output. The values here should precisely match the output from ./configure --help, which I did not think of checking before. Let me check that right now, as I write this very sentence. This is the output: Fine tuning of the installation directories: --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/apache-couchdb] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] I contend that the output of this script should be: --bindir user executables [EPREFIX/bin] --sbindir system admin executables [EPREFIX/sbin] --libexecdir program executables [EPREFIX/libexec] --sysconfdir read-only single-machine data [PREFIX/etc] --sharedstatedir modifiable architecture-independent data [PREFIX/com] --localstatedir modifiable single-machine data [PREFIX/var] --libdir object code libraries [EPREFIX/lib] --includedir C header files [PREFIX/include] --oldincludedir C header files for non-gcc [/usr/include] --datarootdir read-only arch.-independent data root [PREFIX/share] --datadir read-only architecture-independent data [DATAROOTDIR] --infodir info documentation [DATAROOTDIR/info] --localedir locale-dependent data [DATAROOTDIR/locale] --mandir man documentation [DATAROOTDIR/man] --docdir documentation root [DATAROOTDIR/doc/apache-couchdb] --htmldir html documentation [DOCDIR] --dvidir dvi documentation [DOCDIR] --pdfdir pdf documentation [DOCDIR] --psdir ps documentation [DOCDIR] I would also update the help description to read: The $basename command runs the %package_name% environment tool. When %package_name% is installed, certain environment variables are set. This script will display the current values of those variables. See the %package_name% ./configure --help output for more information. The exit status is 0 for success or 1 for failure.
        Hide
        Noah Slater added a comment -

        Oh, forgot to mention, I don't think it matters that we don't necessarily use all of these variables for anything. It maintains consistency with out build system that sets them in the first place. Also, from these, and knowing where CouchDB puts files, you can work out where CouchDB specific sub-directories are. If you can't work out how to get from localstatedir to the place CouchDB keeps it's .couch files, you're not the intended audience for this script.

        Show
        Noah Slater added a comment - Oh, forgot to mention, I don't think it matters that we don't necessarily use all of these variables for anything. It maintains consistency with out build system that sets them in the first place. Also, from these, and knowing where CouchDB puts files, you can work out where CouchDB specific sub-directories are. If you can't work out how to get from localstatedir to the place CouchDB keeps it's .couch files, you're not the intended audience for this script.
        Hide
        Paul Joseph Davis added a comment -

        1. We don't have to alias everything.
        2. You have to be kidding me that you expect people to puzzle over which of those variables is where .couch files are stored.

        There are a couple common use cases that are motivating this tool:

        • Where the hell are the config files?
        • Where the hell are my db files?
        • Where the hell is that URI file?
        • Where the hell do I put beam files?

        These are answers people are looking for when they get frustrated. The last thing people should have to do is "work out where CouchDB specific sub-directories are." I'm biblically familiar with our build system and I can't name every combination of variables and subpaths off the top of my head.

        Bottom line: I can work these things out but I shouldn't have to. I want this tool so that I don't have to recall that localstatedir where where the one things are while the other bits are in `couch-config n --localstatelibdir`/couchdb/erlang/couchdb`couchdb -n --version`/ebin/. Then again maybe I'm just slow and that's more clear than --dbdir.

        Two related notes:

        We should add a -n to affect the echo adding a newline (useful for script substitution as above).

        couchebindir and couchincludedir should be replaced with --erllibdir. There's no reason for ebin dir. The include directory is only useful for compiling other code. After install this is setup as a proper ERL_LIBS directory structure so -include_lib("couchdb/include/couch_db.hrl"). should work with --erllibdir alone.

        Show
        Paul Joseph Davis added a comment - 1. We don't have to alias everything. 2. You have to be kidding me that you expect people to puzzle over which of those variables is where .couch files are stored. There are a couple common use cases that are motivating this tool: Where the hell are the config files? Where the hell are my db files? Where the hell is that URI file? Where the hell do I put beam files? These are answers people are looking for when they get frustrated. The last thing people should have to do is "work out where CouchDB specific sub-directories are." I'm biblically familiar with our build system and I can't name every combination of variables and subpaths off the top of my head. Bottom line: I can work these things out but I shouldn't have to. I want this tool so that I don't have to recall that localstatedir where where the one things are while the other bits are in `couch-config n --localstatelibdir`/couchdb/erlang/couchdb `couchdb -n --version`/ebin/. Then again maybe I'm just slow and that's more clear than --dbdir. Two related notes: We should add a -n to affect the echo adding a newline (useful for script substitution as above). couchebindir and couchincludedir should be replaced with --erllibdir. There's no reason for ebin dir. The include directory is only useful for compiling other code. After install this is setup as a proper ERL_LIBS directory structure so -include_lib("couchdb/include/couch_db.hrl"). should work with --erllibdir alone.
        Hide
        Noah Slater added a comment -

        Okay, how about this:

        Options:

        -h display a short help message and exit
        -V display version information and exit

        Common directories:

        --bindir user executables [EPREFIX/bin]
        --sbindir system admin executables [EPREFIX/sbin]
        --libexecdir program executables [EPREFIX/libexec]
        --sysconfdir read-only single-machine data [PREFIX/etc]
        --sharedstatedir modifiable architecture-independent data [PREFIX/com]
        --localstatedir modifiable single-machine data [PREFIX/var]
        --libdir object code libraries [EPREFIX/lib]
        --includedir C header files [PREFIX/include]
        --oldincludedir C header files for non-gcc [/usr/include]
        --datarootdir read-only arch.-independent data root [PREFIX/share]
        --datadir read-only architecture-independent data [DATAROOTDIR]
        --infodir info documentation [DATAROOTDIR/info]
        --localedir locale-dependent data [DATAROOTDIR/locale]
        --mandir man documentation [DATAROOTDIR/man]
        --docdir documentation root [DATAROOTDIR/doc/apache-couchdb]
        --htmldir html documentation [DOCDIR]
        --dvidir dvi documentation [DOCDIR]
        --pdfdir pdf documentation [DOCDIR]
        --psdir ps documentation [DOCDIR]

        CouchDB directories:

        --localconfdir configuration data [SYSCONFDIR/$package_identifier]
        --localdatadir runtime data [DATADIR/$package_identifier]
        --localdocdir documentation data [DATADIR/doc/$package_identifier]
        --locallibdir library data [LIBDIR/$package_identifier]
        --localstatelibdir database data [LOCALSTATEDIR/lib/$package_identifier]
        --localstatelogdir log data [LOCALSTATEDIR/log/$package_identifier]
        --localstaterundir daemon data [LOCALSTATEDIR/run/$package_identifier]

        Note: the above has been correctly formatted for fixed width display, and $variables will be replaced by the script.

        I think that should be enough. We list all of the default Autoconf stuff, as well as listing the most important variable set specifically for CouchDB. I don't think we should include options such as --uri-file or whatever. This duplicates this information, as it is only stored in one other place in the source, so it would quickly rot. Also, the tiny amount of space we have in the output of this tool is not enough to document these files. That is what the documentation proper is for. This is a tool to allow people already familiar with what they are looking for to print out values.

        The -n output you suggest is not needed:

        $ echo "foo `echo bar` baz"
        foo bar baz

        This would change your example usage of the script to this:

        echo "`couch-config -locallibdir`/ebin/"

        Show
        Noah Slater added a comment - Okay, how about this: Options: -h display a short help message and exit -V display version information and exit Common directories: --bindir user executables [EPREFIX/bin] --sbindir system admin executables [EPREFIX/sbin] --libexecdir program executables [EPREFIX/libexec] --sysconfdir read-only single-machine data [PREFIX/etc] --sharedstatedir modifiable architecture-independent data [PREFIX/com] --localstatedir modifiable single-machine data [PREFIX/var] --libdir object code libraries [EPREFIX/lib] --includedir C header files [PREFIX/include] --oldincludedir C header files for non-gcc [/usr/include] --datarootdir read-only arch.-independent data root [PREFIX/share] --datadir read-only architecture-independent data [DATAROOTDIR] --infodir info documentation [DATAROOTDIR/info] --localedir locale-dependent data [DATAROOTDIR/locale] --mandir man documentation [DATAROOTDIR/man] --docdir documentation root [DATAROOTDIR/doc/apache-couchdb] --htmldir html documentation [DOCDIR] --dvidir dvi documentation [DOCDIR] --pdfdir pdf documentation [DOCDIR] --psdir ps documentation [DOCDIR] CouchDB directories: --localconfdir configuration data [SYSCONFDIR/$package_identifier] --localdatadir runtime data [DATADIR/$package_identifier] --localdocdir documentation data [DATADIR/doc/$package_identifier] --locallibdir library data [LIBDIR/$package_identifier] --localstatelibdir database data [LOCALSTATEDIR/lib/$package_identifier] --localstatelogdir log data [LOCALSTATEDIR/log/$package_identifier] --localstaterundir daemon data [LOCALSTATEDIR/run/$package_identifier] Note: the above has been correctly formatted for fixed width display, and $variables will be replaced by the script. I think that should be enough. We list all of the default Autoconf stuff, as well as listing the most important variable set specifically for CouchDB. I don't think we should include options such as --uri-file or whatever. This duplicates this information, as it is only stored in one other place in the source, so it would quickly rot. Also, the tiny amount of space we have in the output of this tool is not enough to document these files. That is what the documentation proper is for. This is a tool to allow people already familiar with what they are looking for to print out values. The -n output you suggest is not needed: $ echo "foo `echo bar` baz" foo bar baz This would change your example usage of the script to this: echo "`couch-config -locallibdir`/ebin/"
        Hide
        Noah Slater added a comment -

        Oh, it WAS formatted.

        Show
        Noah Slater added a comment - Oh, it WAS formatted.
        Hide
        Paul Joseph Davis added a comment -

        You're just yanking my chain right?

        Show
        Paul Joseph Davis added a comment - You're just yanking my chain right?
        Hide
        Randall Leeds added a comment -

        I'm in favor of couch-config over couchenv. *-config is the convention I'm familiar with. I'd also like to ship a couch.m4, but that's a separate ticket and I'll work with Noah to do that.

        I wonder if it's better not to include the database, view, log directories. I'd prefer the minimal set of things required for developers, and in particular things that can't be changed through CouchDB's configuration system (because things that can possibly make the output of couch-config wrong if they are changed). Feel free to tell me I'm crazy.

        On the one hand, most people won't change these settings in their config, so they could stay in the couch-config tool and likely not report the wrong path.
        On the other hand, most people won't need to read these settings for plugin development, so maybe they're better left out for the sake of simplicity.

        I'm mostly tempted to leave out the db directory to force plugin developers to initialize any special dbs they might need when their plugin is loaded. I think it reduces the likelihood of certain surprises, such as a user deleting a plugin's configuration database by mistake or a plugin author accidentally creating their plugin's config db with root permissions and couch can't read it, etc...

        Otherwise, everything being discussed above sounds reasonable. Seems like you all have it under control. Ship it.

        Show
        Randall Leeds added a comment - I'm in favor of couch-config over couchenv. *-config is the convention I'm familiar with. I'd also like to ship a couch.m4, but that's a separate ticket and I'll work with Noah to do that. I wonder if it's better not to include the database, view, log directories. I'd prefer the minimal set of things required for developers , and in particular things that can't be changed through CouchDB's configuration system (because things that can possibly make the output of couch-config wrong if they are changed). Feel free to tell me I'm crazy. On the one hand, most people won't change these settings in their config, so they could stay in the couch-config tool and likely not report the wrong path. On the other hand, most people won't need to read these settings for plugin development, so maybe they're better left out for the sake of simplicity. I'm mostly tempted to leave out the db directory to force plugin developers to initialize any special dbs they might need when their plugin is loaded. I think it reduces the likelihood of certain surprises, such as a user deleting a plugin's configuration database by mistake or a plugin author accidentally creating their plugin's config db with root permissions and couch can't read it, etc... Otherwise, everything being discussed above sounds reasonable. Seems like you all have it under control. Ship it.
        Hide
        Noah Slater added a comment -

        @Paul, nope? Which bit?

        Show
        Noah Slater added a comment - @Paul, nope? Which bit?
        Hide
        Randall Leeds added a comment -

        Take it home, Noah.

        Show
        Randall Leeds added a comment - Take it home, Noah.
        Hide
        Paul Joseph Davis added a comment -

        @Randall,

        You make a good point about switching configurations away from the install time defaults. I'm not entirely certain that I care too much though. If someone is at the level that they're swapping their lib or db directories then they can hang out in the corner. As to remove the db directory to force developers to do something funny I don't see it. I mean, creating a database at install time? Not even we do that.

        @Noah,

        Look at the list of variables you have. Do we even actually install anything in any of these directories? Maybe the doc directory gets some stuff. But seriously, dvi, pdf, and ps directories?

        --sbindir system admin executables [EPREFIX/sbin]
        --libexecdir program executables [EPREFIX/libexec]
        --sharedstatedir modifiable architecture-independent data [PREFIX/com]
        --infodir info documentation [DATAROOTDIR/info]
        --localedir locale-dependent data [DATAROOTDIR/locale]
        --docdir documentation root [DATAROOTDIR/doc/apache-couchdb]
        --htmldir html documentation [DOCDIR]
        --dvidir dvi documentation [DOCDIR]
        --pdfdir pdf documentation [DOCDIR]
        --psdir ps documentation [DOCDIR]

        And then in the CouchDB section:

        --localconfdir configuration data [SYSCONFDIR/$package_identifier]
        --localdatadir runtime data [DATADIR/$package_identifier]
        --localdocdir documentation data [DATADIR/doc/$package_identifier]
        --locallibdir library data [LIBDIR/$package_identifier]
        --localstatelibdir database data [LOCALSTATEDIR/lib/$package_identifier]
        --localstatelogdir log data [LOCALSTATEDIR/log/$package_identifier]
        --localstaterundir daemon data [LOCALSTATEDIR/run/$package_identifier]

        What in the world does "local" mean here? Do you seriously expect users that aren't autotools experts to have any clue what this stuff means? Consider this as compared to:

        --config-dir configuration directory
        --db-dir database directory
        --static-dir static asset directory
        --doc-dir documentation directory
        --erl-libs-dir Erlang library directory
        --log-dir log directory
        --pid-file daemon PID file
        --uri-file daemon sockets file

        Its almost pointless to even include a description line for these variable names. And why aren't the CouchDB specific directories first? How often do you expect someone to want to know about the DVI or PDF directory before the db, log, or erl-libs directory?

        I'm not saying we have to get rid of the dvi and ps directories. Its quite possible they'll get used at some point but the user friendly alias options should be first. Otherwise you force every user to learn and remember what locallibdir is compared to localdatadir compared to localstaterundir.

        What happened to the old Noah that loved and cared about our users? The Noah that would treat our users like a small furry rabbit to cuddle. Furry rabbits like this little guy:

        http://28.media.tumblr.com/tumblr_lq2sexkiya1qzp2x4o1_500.jpg

        Show
        Paul Joseph Davis added a comment - @Randall, You make a good point about switching configurations away from the install time defaults. I'm not entirely certain that I care too much though. If someone is at the level that they're swapping their lib or db directories then they can hang out in the corner. As to remove the db directory to force developers to do something funny I don't see it. I mean, creating a database at install time? Not even we do that. @Noah, Look at the list of variables you have. Do we even actually install anything in any of these directories? Maybe the doc directory gets some stuff. But seriously, dvi, pdf, and ps directories? --sbindir system admin executables [EPREFIX/sbin] --libexecdir program executables [EPREFIX/libexec] --sharedstatedir modifiable architecture-independent data [PREFIX/com] --infodir info documentation [DATAROOTDIR/info] --localedir locale-dependent data [DATAROOTDIR/locale] --docdir documentation root [DATAROOTDIR/doc/apache-couchdb] --htmldir html documentation [DOCDIR] --dvidir dvi documentation [DOCDIR] --pdfdir pdf documentation [DOCDIR] --psdir ps documentation [DOCDIR] And then in the CouchDB section: --localconfdir configuration data [SYSCONFDIR/$package_identifier] --localdatadir runtime data [DATADIR/$package_identifier] --localdocdir documentation data [DATADIR/doc/$package_identifier] --locallibdir library data [LIBDIR/$package_identifier] --localstatelibdir database data [LOCALSTATEDIR/lib/$package_identifier] --localstatelogdir log data [LOCALSTATEDIR/log/$package_identifier] --localstaterundir daemon data [LOCALSTATEDIR/run/$package_identifier] What in the world does "local" mean here? Do you seriously expect users that aren't autotools experts to have any clue what this stuff means? Consider this as compared to: --config-dir configuration directory --db-dir database directory --static-dir static asset directory --doc-dir documentation directory --erl-libs-dir Erlang library directory --log-dir log directory --pid-file daemon PID file --uri-file daemon sockets file Its almost pointless to even include a description line for these variable names. And why aren't the CouchDB specific directories first? How often do you expect someone to want to know about the DVI or PDF directory before the db, log, or erl-libs directory? I'm not saying we have to get rid of the dvi and ps directories. Its quite possible they'll get used at some point but the user friendly alias options should be first. Otherwise you force every user to learn and remember what locallibdir is compared to localdatadir compared to localstaterundir. What happened to the old Noah that loved and cared about our users? The Noah that would treat our users like a small furry rabbit to cuddle. Furry rabbits like this little guy: http://28.media.tumblr.com/tumblr_lq2sexkiya1qzp2x4o1_500.jpg
        Hide
        Randall Leeds added a comment -

        I think we're getting carried away.

        localstatelibdir (db-dir), localstatelogdir (log-dir) should disappear from here. localstatedir is the only variable that matters to autotools[1] and we don't even accept the others as flags to configure. I'd drop pid-file, uri-file and all the autotools stuff because it's not relevant for developing modules for couchdb. It's relevant for building and running couchdb, when the values are either being passed by the packager or set by the operator.

        Something like --libdir to mean the erlang lib dir for all the erlang modules we install and --configdir to be the directory containing local.d and default.d.

        That's all developers should need. If developers of plugins want to install documentation of various formats they can do their own autotools dance. The documentation and supporting tooling or whatever else somone might package together with a couchdb module and how they distribute it is not our concern, but unless we provide a way for developers to modify the erlang code path we need them to install to our --libdir. Otherwise, it's just erlang modules that couch can load via its hooks in the .ini system. We shouldn't overthink this.

        [1] https://www.gnu.org/s/hello/manual/autoconf/Installation-Directory-Variables.html

        Show
        Randall Leeds added a comment - I think we're getting carried away. localstatelibdir (db-dir), localstatelogdir (log-dir) should disappear from here. localstatedir is the only variable that matters to autotools [1] and we don't even accept the others as flags to configure. I'd drop pid-file, uri-file and all the autotools stuff because it's not relevant for developing modules for couchdb. It's relevant for building and running couchdb, when the values are either being passed by the packager or set by the operator. Something like --libdir to mean the erlang lib dir for all the erlang modules we install and --configdir to be the directory containing local.d and default.d. That's all developers should need. If developers of plugins want to install documentation of various formats they can do their own autotools dance. The documentation and supporting tooling or whatever else somone might package together with a couchdb module and how they distribute it is not our concern, but unless we provide a way for developers to modify the erlang code path we need them to install to our --libdir. Otherwise, it's just erlang modules that couch can load via its hooks in the .ini system. We shouldn't overthink this. [1] https://www.gnu.org/s/hello/manual/autoconf/Installation-Directory-Variables.html
        Hide
        Randall Leeds added a comment -

        I'm just going to trust Noah here, but I'd like to see CouchDB-specific options listed first and to see the reconfigurable options left out: localstate*dir.
        I think localdatadir needs to be there, but should be renamed to reflect what it is: static resources used by the HTTP server (futon, js tests, etc). Not sure what name that should be.

        How about this list:

        CouchDB variables:
        --couchconfdir configuration data [SYSCONFDIR/$package_identifier]
        --couchstaticroot runtime data [DATADIR/$package_identifier]
        ^^ please help me name this one
        --couchlibdir library data [LIBDIR/$package_identifier]
        ^^ this should be the ..../erlang/lib dir, either the system erlang (Windows and CentOS packages do this) or Couch's private one in LIBDIR/couchdb/erlang/lib

        Other variables:

        We don't install to most of these. It's strange to me that autoconf still generates a configure with all these options even when we don't use most of them.
        I'm fine with keeping any and all of them, as long as we list it after the CouchDB ones.
        --libexecdir program executables [EPREFIX/libexec]
        --sharedstatedir modifiable architecture-independent data [PREFIX/com]
        --infodir info documentation [DATAROOTDIR/info]
        --localedir locale-dependent data [DATAROOTDIR/locale]
        --docdir documentation root [DATAROOTDIR/doc/apache-couchdb]
        --htmldir html documentation [DOCDIR]
        --dvidir dvi documentation [DOCDIR]
        --pdfdir pdf documentation [DOCDIR]
        --psdir ps documentation [DOCDIR]

        Is this getting closer?

        Show
        Randall Leeds added a comment - I'm just going to trust Noah here, but I'd like to see CouchDB-specific options listed first and to see the reconfigurable options left out: localstate*dir. I think localdatadir needs to be there, but should be renamed to reflect what it is: static resources used by the HTTP server (futon, js tests, etc). Not sure what name that should be. How about this list: CouchDB variables: --couchconfdir configuration data [SYSCONFDIR/$package_identifier] --couchstaticroot runtime data [DATADIR/$package_identifier] ^^ please help me name this one --couchlibdir library data [LIBDIR/$package_identifier] ^^ this should be the ..../erlang/lib dir, either the system erlang (Windows and CentOS packages do this) or Couch's private one in LIBDIR/couchdb/erlang/lib Other variables: We don't install to most of these. It's strange to me that autoconf still generates a configure with all these options even when we don't use most of them. I'm fine with keeping any and all of them, as long as we list it after the CouchDB ones. --libexecdir program executables [EPREFIX/libexec] --sharedstatedir modifiable architecture-independent data [PREFIX/com] --infodir info documentation [DATAROOTDIR/info] --localedir locale-dependent data [DATAROOTDIR/locale] --docdir documentation root [DATAROOTDIR/doc/apache-couchdb] --htmldir html documentation [DOCDIR] --dvidir dvi documentation [DOCDIR] --pdfdir pdf documentation [DOCDIR] --psdir ps documentation [DOCDIR] Is this getting closer?
        Hide
        Paul Joseph Davis added a comment -

        couch-config --couchconfdir

        vs

        couch-config --cfg-dir

        Am I the only one scratching their head why this is so complicated?

        Show
        Paul Joseph Davis added a comment - couch-config --couchconfdir vs couch-config --cfg-dir Am I the only one scratching their head why this is so complicated?
        Hide
        Randall Leeds added a comment -

        Assigning back to me since I'm almost done cleaning this up.

        Show
        Randall Leeds added a comment - Assigning back to me since I'm almost done cleaning this up.
        Hide
        Benoit Chesneau added a comment -

        @tilgovi At some point I would prefer to clean myself the patch I've done though.

        To answer to noah . The variables name I've chosen at first was the one you can find in most of *-config file (incdir, ..). Especially if I some time couchdb become a full erlang release embedded or not. You don't want to change the variable meaning each time. Also for a couchdb developers or admin I think it's more clear to say --db-dir rather than localibdir or whatever is the variable. Having uri dir is also more useful than having a simple run directory. couch-config is related to couchdb after-all not a simple generic program.

        Anyway let's try to summarize changes here before I go for a patch:

        -h --> --help

        Other var dirs ? I'm full for this one :

        --config-dir configuration directory
        --db-dir database directory
        --static-dir static asset directory
        --doc-dir documentation directory
        --erl-libs-dir Erlang library directory
        --log-dir log directory
        --pid-file daemon PID file
        --uri-file daemon sockets file

        no real need to add a "couch" namesmace. This is again the couch-config command line. I think it's ok to put here the generated varaiab les during the configure step. If someone change teh ini file, he already know what to do and what are paths. Most of devs and admin won't change these variables. I can put a new patch asap if we are OK with above.

        Show
        Benoit Chesneau added a comment - @tilgovi At some point I would prefer to clean myself the patch I've done though. To answer to noah . The variables name I've chosen at first was the one you can find in most of *-config file (incdir, ..). Especially if I some time couchdb become a full erlang release embedded or not. You don't want to change the variable meaning each time. Also for a couchdb developers or admin I think it's more clear to say --db-dir rather than localibdir or whatever is the variable. Having uri dir is also more useful than having a simple run directory. couch-config is related to couchdb after-all not a simple generic program. Anyway let's try to summarize changes here before I go for a patch: -h --> --help Other var dirs ? I'm full for this one : --config-dir configuration directory --db-dir database directory --static-dir static asset directory --doc-dir documentation directory --erl-libs-dir Erlang library directory --log-dir log directory --pid-file daemon PID file --uri-file daemon sockets file no real need to add a "couch" namesmace. This is again the couch-config command line. I think it's ok to put here the generated varaiab les during the configure step. If someone change teh ini file, he already know what to do and what are paths. Most of devs and admin won't change these variables. I can put a new patch asap if we are OK with above.
        Hide
        Paul Joseph Davis added a comment -

        @Benoit

        That's exactly what I'm looking for. Only comment is that we should include the -V for version info as well.

        Show
        Paul Joseph Davis added a comment - @Benoit That's exactly what I'm looking for. Only comment is that we should include the -V for version info as well.
        Hide
        Noah Slater added a comment -

        All of my original comments still hold, with regard to formatting, and help2man, etc.

        Why --erl-libs-dir and not --libs-dir?

        Can someone answer this concern too:

        "I'd drop pid-file, uri-file and all the autotools stuff because it's not relevant for developing modules for couchdb."

        Why is --pid-file and --uri-file still in this suggested output?

        Why do we include --doc-dir, too, etc?

        Show
        Noah Slater added a comment - All of my original comments still hold, with regard to formatting, and help2man, etc. Why --erl-libs-dir and not --libs-dir? Can someone answer this concern too: "I'd drop pid-file, uri-file and all the autotools stuff because it's not relevant for developing modules for couchdb." Why is --pid-file and --uri-file still in this suggested output? Why do we include --doc-dir, too, etc?
        Hide
        Paul Joseph Davis added a comment -

        The suggestion was --elib-dir over --lib-dir because --lib-dir might be assumed to point at /usr/local/lib and it was hoped that --elib-dir would be recognized as the place where developers should install their erlang modules.

        As to:

        "I'd drop pid-file, uri-file and all the autotools stuff because it's not relevant for developing modules for couchdb."

        Randall was focusing on developers writing extensions for CouchDB (which was the original genesis of this feature). Dropping those suggestions focuses back on the original motivation for this discussion.

        The pid-file and uri-file are part of the suggestion because they're part of the larger idea of a tool that sysadmin/packagers/developers can use to locate important bits of a CouchDB installation.

        I have no specific input on including or excluding a --doc-dir switch.

        Show
        Paul Joseph Davis added a comment - The suggestion was --elib-dir over --lib-dir because --lib-dir might be assumed to point at /usr/local/lib and it was hoped that --elib-dir would be recognized as the place where developers should install their erlang modules. As to: "I'd drop pid-file, uri-file and all the autotools stuff because it's not relevant for developing modules for couchdb." Randall was focusing on developers writing extensions for CouchDB (which was the original genesis of this feature). Dropping those suggestions focuses back on the original motivation for this discussion. The pid-file and uri-file are part of the suggestion because they're part of the larger idea of a tool that sysadmin/packagers/developers can use to locate important bits of a CouchDB installation. I have no specific input on including or excluding a --doc-dir switch.
        Hide
        Randall Leeds added a comment -

        @Noah:

        To re-iterate my position and offer a couple reasons:

        The localstate__dir options aren't configurable at build time, they're just created based on localstatedir, so I'll reiterate my desire to exclude them.They're not configurable at runtime, it's generally suggested that they be owned by the couchdb user (therefore not necessarily even readable by someone using this script except at install-with-root-privs time), and deducible from localstatedir.

        So my vote is to:

        • Exclude localstate__dir
        • Include package-name or package-identifier so authors can deduce the paths to couch things based on localstatedir, datarootdir, etc...
        • Include elibdir just because by default on *nix we don't install into the default erlang module path but our own private one and we need a name for this place

        Then we don't even need any CouchDB-specific anything and it's all in one section.

        Show
        Randall Leeds added a comment - @Noah: To re-iterate my position and offer a couple reasons: The localstate__dir options aren't configurable at build time, they're just created based on localstatedir, so I'll reiterate my desire to exclude them.They're not configurable at runtime, it's generally suggested that they be owned by the couchdb user (therefore not necessarily even readable by someone using this script except at install-with-root-privs time), and deducible from localstatedir. So my vote is to: Exclude localstate__dir Include package-name or package-identifier so authors can deduce the paths to couch things based on localstatedir, datarootdir, etc... Include elibdir just because by default on *nix we don't install into the default erlang module path but our own private one and we need a name for this place Then we don't even need any CouchDB-specific anything and it's all in one section.
        Hide
        Benoit Chesneau added a comment -

        new version of the patch that should close this ticket.

        new usage:

        add couch-config file used to ease the build of plugin

        Usage :

        $ ./bin/couch-config_dev
        Usage: couch-config_dev [OPTION]

        The couch-config_dev command runs the Apache CouchDB configuration
        helper
        script.

        Options:

        --erl-libs-dir Erlang library directory
        --config-dir configuration directory
        --db-dir database dirrectory
        --view-dir view index directory
        --static-dir static asset directory
        --doc-dir documentation directory
        --uri-file daemon sockets file
        --log-file log file
        --couch-version version of Apache CouchDB
        --couch-bin couchdb binary
        --version version of couch-config_dev
        --help Print usage

        Report bugs at <https://issues.apache.org/jira/browse/COUCHDB>.

        I kept log-file since, we have only a log file. Once jan will commit access log (already in couchbase) we could add access-log as well. Also since view dir can be different I kept this option as well.

        If it's OK will commit it later today.

        Show
        Benoit Chesneau added a comment - new version of the patch that should close this ticket. new usage: add couch-config file used to ease the build of plugin Usage : $ ./bin/couch-config_dev Usage: couch-config_dev [OPTION] The couch-config_dev command runs the Apache CouchDB configuration helper script. Options: --erl-libs-dir Erlang library directory --config-dir configuration directory --db-dir database dirrectory --view-dir view index directory --static-dir static asset directory --doc-dir documentation directory --uri-file daemon sockets file --log-file log file --couch-version version of Apache CouchDB --couch-bin couchdb binary --version version of couch-config_dev --help Print usage Report bugs at < https://issues.apache.org/jira/browse/COUCHDB >. I kept log-file since, we have only a log file. Once jan will commit access log (already in couchbase) we could add access-log as well. Also since view dir can be different I kept this option as well. If it's OK will commit it later today.
        Hide
        Benoit Chesneau added a comment -

        forgot to say I added couch-version options to ease resolution of couchdb versions.

        Show
        Benoit Chesneau added a comment - forgot to say I added couch-version options to ease resolution of couchdb versions.
        Hide
        Noah Slater added a comment -

        Why not just --log-dir?

        Why do we have --couch-bin now?

        Why is it called couchdb-config_dev now?

        I am confused about this script. It seems that we all have very different ideas about how it is going to be used. Paul has previously argued for a very limited set of options for module developers only, and I must say that I favour that approach. Realistically, who is going to call this script to find out where the `couchdb` script is?

        How about this approach:

        • We completely strip down the options here to the very bare essentials needed to develop CouchDB modules.
        • We add a note to the --help output saying that we're open to suggestions for new options.
        • We implement new options once it becomes apparent what he use case is.
        Show
        Noah Slater added a comment - Why not just --log-dir? Why do we have --couch-bin now? Why is it called couchdb-config_dev now? I am confused about this script. It seems that we all have very different ideas about how it is going to be used. Paul has previously argued for a very limited set of options for module developers only, and I must say that I favour that approach. Realistically, who is going to call this script to find out where the `couchdb` script is? How about this approach: We completely strip down the options here to the very bare essentials needed to develop CouchDB modules. We add a note to the --help output saying that we're open to suggestions for new options. We implement new options once it becomes apparent what he use case is.
        Hide
        Benoit Chesneau added a comment -

        it's not called couch-config_dev. 2 files are created to handle dev mode (can be removed). Sorry should have been put the example with couch-config. Code is saying the truth though.

        It's not called log-dir because what we really have is a log file, but can be log dir those that won't give the name of the log file. Is this the way to follow?

        I find it useful to have couchdb bin path but can be removed as well. All other options are needed though. adding a note is a good idea, what would be the text?

        Show
        Benoit Chesneau added a comment - it's not called couch-config_dev. 2 files are created to handle dev mode (can be removed). Sorry should have been put the example with couch-config. Code is saying the truth though. It's not called log-dir because what we really have is a log file, but can be log dir those that won't give the name of the log file. Is this the way to follow? I find it useful to have couchdb bin path but can be removed as well. All other options are needed though. adding a note is a good idea, what would be the text?
        Hide
        Benoit Chesneau added a comment -

        new version of the patch. It remove couchdb-bin option, rename log-file to log-dir (and only show log dir) . add a not to invite users to ask for more options.

        New usage:

        $ ./bin/couch-config
        Usage: couch-config [OPTION]

        The couch-config command runs the Apache CouchDB configuration helper
        script.

        Options:

        --erl-libs-dir Erlang library directory
        --config-dir configuration directory
        --db-dir database dirrectory
        --view-dir view index directory
        --static-dir static asset directory
        --doc-dir documentation directory
        --log-dir log directory
        --uri-file daemon sockets file
        --couch-version version of Apache CouchDB
        --version version of couch-config
        --help Print usage

        If you want to add an option in couch-config or report bugs please do it
        at <https://issues.apache.org/jira/browse/COUCHDB>.

        ok?

        Show
        Benoit Chesneau added a comment - new version of the patch. It remove couchdb-bin option, rename log-file to log-dir (and only show log dir) . add a not to invite users to ask for more options. New usage: $ ./bin/couch-config Usage: couch-config [OPTION] The couch-config command runs the Apache CouchDB configuration helper script. Options: --erl-libs-dir Erlang library directory --config-dir configuration directory --db-dir database dirrectory --view-dir view index directory --static-dir static asset directory --doc-dir documentation directory --log-dir log directory --uri-file daemon sockets file --couch-version version of Apache CouchDB --version version of couch-config --help Print usage If you want to add an option in couch-config or report bugs please do it at < https://issues.apache.org/jira/browse/COUCHDB >. ok?
        Hide
        Noah Slater added a comment -

        Benoit, just commit your patch. I'll take a look at the code after you've done that and make any changes I want to make for consistency or compatibility with help2man, etc. Too much discussion for such a small script. Let's just iterate on this with actual changesets instead.

        Show
        Noah Slater added a comment - Benoit, just commit your patch. I'll take a look at the code after you've done that and make any changes I want to make for consistency or compatibility with help2man, etc. Too much discussion for such a small script. Let's just iterate on this with actual changesets instead.
        Hide
        Benoit Chesneau added a comment -

        applied in trunk revision 1161695

        Show
        Benoit Chesneau added a comment - applied in trunk revision 1161695

          People

          • Assignee:
            Benoit Chesneau
            Reporter:
            Randall Leeds
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development