I think this is reasonable. So, default is 'light logging'. As a module it is no logging. As an option it is very verbose java style logging.
On Thu, Sep 5, 2013 at 12:36 PM, Michal Mocny <mmo...@chromium.org> wrote: > No one likes spam, but I also don't consider cordova-cli a tiny isolated > tool for composable usage in the unix toolbox, and so it shouldn't be > striving to meet those particular requirements. Pragmatically speaking I > think cordova-cli should print small but useful bit of status information. > > However, it would be desirable to have nothing printed when cordova is > being consumed as a node module, and only do so when actually run from a > console using the cordova binary directly. > > -Michal > > > On Thu, Sep 5, 2013 at 3:14 PM, Carlos Santana <csantan...@gmail.com> > wrote: > > > I would like to see by default some type of minimal high level progress > > information, not crazy massive output like npm with warnings when stuff > is > > working > > > > - fetching files from [network, cached] > > - adding files [platforms/ios] > > - modifying file [plugins/ios.json] > > - merging files [merges/ios] > > - running hooks [..] > > - running platform script [platforms/ios/bin/create] > > > > > > Sometimes I think the cli is broken, because it doesn't return and no > > output is given. and its a matter of waiting a while. or just wait for > the > > cli to fail > > I feel like waiting for a surprise, surprise it finish run echo $? or > > surprise you waited enough to see the failed message. > > > > > > I agree log/verbose levels should be a good enhancement > > > > > > > > On Wed, Sep 4, 2013 at 9:08 PM, Andrew Grieve <agri...@chromium.org> > > wrote: > > > > > I don't think your attachment worked. > > > > > > > > > On Wed, Sep 4, 2013 at 5:03 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > > > Composability being the big reasoning. Maybe that is a false > > > consideration > > > > for our end users. I know I hate chatty tools (and I hate telling > them > > to > > > > be quiet) and that could just be a preference from java scars. > > > > > > > > Some very light reading attached from 'Classic Shell Scripting' > > regarding > > > > UNIX tools philosophy. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 4, 2013 at 1:38 PM, Andrew Grieve <agri...@chromium.org > > > >wrote: > > > > > > > >> cd and rm don't make network requests. There's plenty of precedent > for > > > >> outputting by default. zip, wget, rsync, apt-get, brew. > > > >> > > > >> You can always use --quiet if you pipe our command and have it not > > > output. > > > >> Am I missing something about your use-case? > > > >> > > > >> We have a practical problem right now in that we get a lot of bad > bug > > > >> reports where we need to tell users to re-run with --verbose. Almost > > > every > > > >> day in IRC, someone gets told to re-run with --verbose. > > > >> > > > >> > > > >> On Wed, Sep 4, 2013 at 4:23 PM, Brian LeRoux <b...@brian.io> wrote: > > > >> > > > >> > Well, those aren't UNIX tools. Those are userland tools. (So are > > we, I > > > >> > know.) > > > >> > > > > >> > Imagine if `cd` output something every time you moved. Or rm was > > > always > > > >> > noisy. Super annoying. Anyhow, the book Classic Shell Scripting > > > explains > > > >> > this better than I. Recommended reading. > > > >> > > > > >> > I'd rather our tools followed UNIX philosophy here and where quiet > > by > > > >> > defaul and noisy if asked. For the record, I've talked to Issac > > about > > > >> just > > > >> > this issue in node b/c it makes composing scripts more difficult > > when > > > >> you > > > >> > have to pipe garbage output around and a tacit plan for npm was to > > > make > > > >> it > > > >> > quiet by default someday when it gets stable. (Who knows if that > is > > > >> still > > > >> > the case.) > > > >> > > > > >> > > > > >> > On Wed, Sep 4, 2013 at 1:01 PM, Andrew Grieve < > agri...@chromium.org > > > > > > >> > wrote: > > > >> > > > > >> > > I don't think that's really true for other similar tools. > > > >> > > E.g. "npm install" reports progress by default > > > >> > > E.g. "git clone" shows progress by default. > > > >> > > > > > >> > > > > > >> > > On Wed, Sep 4, 2013 at 3:51 PM, Brian LeRoux <b...@brian.io> > wrote: > > > >> > > > > > >> > > > The convention for UNIX tools is to be quiet by default and > fail > > > >> > > noisily. A > > > >> > > > well writ script should exit quietly so you can chain > commands. > > > (Or > > > >> > pipe, > > > >> > > > etc.) > > > >> > > > > > > >> > > > I'd prefer we added a --verbose flag. > > > >> > > > > > > >> > > > > > > >> > > > On Wed, Sep 4, 2013 at 12:35 PM, Braden Shepherdson < > > > >> > bra...@chromium.org > > > >> > > > >wrote: > > > >> > > > > > > >> > > > > I'd rather we call it -q and --quiet though; that's a pretty > > > >> common > > > >> > > > > convention for Unix tools. > > > >> > > > > > > > >> > > > > > > > >> > > > > On Wed, Sep 4, 2013 at 3:35 PM, Braden Shepherdson < > > > >> > > bra...@chromium.org > > > >> > > > > >wrote: > > > >> > > > > > > > >> > > > > > +1 > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > On Wed, Sep 4, 2013 at 3:31 PM, Andrew Grieve < > > > >> > agri...@chromium.org > > > >> > > > > >wrote: > > > >> > > > > > > > > >> > > > > >> I think this was discussed before but I can't find the > > > thread. > > > >> > > > > >> > > > >> > > > > >> Is anyone not in favour of making the tools verbose by > > > default > > > >> and > > > >> > > > > having > > > >> > > > > >> a > > > >> > > > > >> --silent flag instead? > > > >> > > > > >> > > > >> > > > > >> Makes it much easier to get good debug reports and lets > > users > > > >> know > > > >> > > > when > > > >> > > > > >> slow things are taking place. > > > >> > > > > >> > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > -- > > Carlos Santana > > <csantan...@gmail.com> > > >
