CLI and cordova-lib design/extraction

[Brian LeRoux <b...@brian.io>]

In another thread Michal asks,
"How much of CLI's stay in cli: is it a *really* dumb wrapper that parses input
in a generic fashion and turns it into dumb require() calls with opt's?  Or
does it understand the full spec and massage opts into the forms cordova-lib-*
expect  (both options have value!)"


I like the idea of really dumb wrapper but would like to better understand
the ideas with more logic (maybe api style?) in the CLI.

Re: CLI and cordova-lib design/extraction

[Michal Mocny <mm...@chromium.org>]

CLI argument parsing as distinct node module.  Like it.


On Tue, Apr 22, 2014 at 12:33 PM, Brian LeRoux <b...@brian.io> wrote:

> ya I don't see those goals at odds and would love a proper node api, with
> callbacks returning an error or null as the first arg, in addition to
> something that deals w/ massaging cli input
>
>
> On Tue, Apr 22, 2014 at 9:02 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > I was about to suggest exactly this. I already did part of this with the
> > promises refactoring; we should continue it. Mixing the arg-parsing and
> > actual logic is no good.
> >
> > Braden
> >
> >
> > On Tue, Apr 22, 2014 at 11:26 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > I think the biggest win is to do both.
> > >
> > > i.e., have an API that makes sense to library consumers, and then have
> a
> > > cordova-cli-lib, which provides arg-parsing ontop of the
> > > makes-sense-to-consumers API.
> > >
> > >
> > > On Thu, Apr 17, 2014 at 5:43 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > > > Few considerations that come to mind right away, but I have no
> opinions
> > > one
> > > > way or the other yet.
> > > >
> > > > Pro's for Dumber CLI:
> > > > - Easier to support liberal dependency versioning (aka, don't need
> > weekly
> > > > CLI releases as part of cordova-lib updates)
> > > > - ..as part of liberal deps, it may make it easier to supporting one
> > > global
> > > > CLI install support multiple cordova workspaces at different versions
> > > > (which has not been a terrible problem for us so far, but could be).
> > > > - Potentially easier for downstream CLI to be in-sync with their
> > > > functionality, if they hand off more args handling to cordova-lib
> > > > implementations
> > > >
> > > > Pro's for Smarter CLI:
> > > > - cordova-lib API's can be more "formal".  Aka node style vs string
> arg
> > > > parsing / generic array/dict of args passing.
> > > > - ..and if cordova-lib API's are more node style, easier to build
> > better
> > > > tools/tests for automation on top of them.
> > > > - Generic/Dumb arg parsing may be difficult (or impossible) (Mark
> > > > mentioned: especially with handling of optional positional arguments,
> > but
> > > > may be more cases).
> > > > - ..thus current CLI interface may need to change if not all current
> > > > command formats can be handled generically (though, change may not be
> > > bad)
> > > >
> > > >
> > > >
> > > > On Thu, Apr 17, 2014 at 5:11 PM, Brian LeRoux <b...@brian.io> wrote:
> > > >
> > > > > In another thread Michal asks,
> > > > > "How much of CLI's stay in cli: is it a *really* dumb wrapper that
> > > parses
> > > > > input
> > > > > in a generic fashion and turns it into dumb require() calls with
> > opt's?
> > > >  Or
> > > > > does it understand the full spec and massage opts into the forms
> > > > > cordova-lib-*
> > > > > expect  (both options have value!)"
> > > > >
> > > > >
> > > > > I like the idea of really dumb wrapper but would like to better
> > > > understand
> > > > > the ideas with more logic (maybe api style?) in the CLI.
> > > > >
> > > >
> > >
> >
>

Re: CLI and cordova-lib design/extraction

[Brian LeRoux <b...@brian.io>]

ya I don't see those goals at odds and would love a proper node api, with
callbacks returning an error or null as the first arg, in addition to
something that deals w/ massaging cli input


On Tue, Apr 22, 2014 at 9:02 AM, Braden Shepherdson <br...@chromium.org>wrote:

> I was about to suggest exactly this. I already did part of this with the
> promises refactoring; we should continue it. Mixing the arg-parsing and
> actual logic is no good.
>
> Braden
>
>
> On Tue, Apr 22, 2014 at 11:26 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > I think the biggest win is to do both.
> >
> > i.e., have an API that makes sense to library consumers, and then have a
> > cordova-cli-lib, which provides arg-parsing ontop of the
> > makes-sense-to-consumers API.
> >
> >
> > On Thu, Apr 17, 2014 at 5:43 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > Few considerations that come to mind right away, but I have no opinions
> > one
> > > way or the other yet.
> > >
> > > Pro's for Dumber CLI:
> > > - Easier to support liberal dependency versioning (aka, don't need
> weekly
> > > CLI releases as part of cordova-lib updates)
> > > - ..as part of liberal deps, it may make it easier to supporting one
> > global
> > > CLI install support multiple cordova workspaces at different versions
> > > (which has not been a terrible problem for us so far, but could be).
> > > - Potentially easier for downstream CLI to be in-sync with their
> > > functionality, if they hand off more args handling to cordova-lib
> > > implementations
> > >
> > > Pro's for Smarter CLI:
> > > - cordova-lib API's can be more "formal".  Aka node style vs string arg
> > > parsing / generic array/dict of args passing.
> > > - ..and if cordova-lib API's are more node style, easier to build
> better
> > > tools/tests for automation on top of them.
> > > - Generic/Dumb arg parsing may be difficult (or impossible) (Mark
> > > mentioned: especially with handling of optional positional arguments,
> but
> > > may be more cases).
> > > - ..thus current CLI interface may need to change if not all current
> > > command formats can be handled generically (though, change may not be
> > bad)
> > >
> > >
> > >
> > > On Thu, Apr 17, 2014 at 5:11 PM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > In another thread Michal asks,
> > > > "How much of CLI's stay in cli: is it a *really* dumb wrapper that
> > parses
> > > > input
> > > > in a generic fashion and turns it into dumb require() calls with
> opt's?
> > >  Or
> > > > does it understand the full spec and massage opts into the forms
> > > > cordova-lib-*
> > > > expect  (both options have value!)"
> > > >
> > > >
> > > > I like the idea of really dumb wrapper but would like to better
> > > understand
> > > > the ideas with more logic (maybe api style?) in the CLI.
> > > >
> > >
> >
>

Re: CLI and cordova-lib design/extraction

[Braden Shepherdson <br...@chromium.org>]

I was about to suggest exactly this. I already did part of this with the
promises refactoring; we should continue it. Mixing the arg-parsing and
actual logic is no good.

Braden


On Tue, Apr 22, 2014 at 11:26 AM, Andrew Grieve <ag...@chromium.org>wrote:

> I think the biggest win is to do both.
>
> i.e., have an API that makes sense to library consumers, and then have a
> cordova-cli-lib, which provides arg-parsing ontop of the
> makes-sense-to-consumers API.
>
>
> On Thu, Apr 17, 2014 at 5:43 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > Few considerations that come to mind right away, but I have no opinions
> one
> > way or the other yet.
> >
> > Pro's for Dumber CLI:
> > - Easier to support liberal dependency versioning (aka, don't need weekly
> > CLI releases as part of cordova-lib updates)
> > - ..as part of liberal deps, it may make it easier to supporting one
> global
> > CLI install support multiple cordova workspaces at different versions
> > (which has not been a terrible problem for us so far, but could be).
> > - Potentially easier for downstream CLI to be in-sync with their
> > functionality, if they hand off more args handling to cordova-lib
> > implementations
> >
> > Pro's for Smarter CLI:
> > - cordova-lib API's can be more "formal".  Aka node style vs string arg
> > parsing / generic array/dict of args passing.
> > - ..and if cordova-lib API's are more node style, easier to build better
> > tools/tests for automation on top of them.
> > - Generic/Dumb arg parsing may be difficult (or impossible) (Mark
> > mentioned: especially with handling of optional positional arguments, but
> > may be more cases).
> > - ..thus current CLI interface may need to change if not all current
> > command formats can be handled generically (though, change may not be
> bad)
> >
> >
> >
> > On Thu, Apr 17, 2014 at 5:11 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > In another thread Michal asks,
> > > "How much of CLI's stay in cli: is it a *really* dumb wrapper that
> parses
> > > input
> > > in a generic fashion and turns it into dumb require() calls with opt's?
> >  Or
> > > does it understand the full spec and massage opts into the forms
> > > cordova-lib-*
> > > expect  (both options have value!)"
> > >
> > >
> > > I like the idea of really dumb wrapper but would like to better
> > understand
> > > the ideas with more logic (maybe api style?) in the CLI.
> > >
> >
>

Re: CLI and cordova-lib design/extraction

[Andrew Grieve <ag...@chromium.org>]

I think the biggest win is to do both.

i.e., have an API that makes sense to library consumers, and then have a
cordova-cli-lib, which provides arg-parsing ontop of the
makes-sense-to-consumers API.


On Thu, Apr 17, 2014 at 5:43 PM, Michal Mocny <mm...@chromium.org> wrote:

> Few considerations that come to mind right away, but I have no opinions one
> way or the other yet.
>
> Pro's for Dumber CLI:
> - Easier to support liberal dependency versioning (aka, don't need weekly
> CLI releases as part of cordova-lib updates)
> - ..as part of liberal deps, it may make it easier to supporting one global
> CLI install support multiple cordova workspaces at different versions
> (which has not been a terrible problem for us so far, but could be).
> - Potentially easier for downstream CLI to be in-sync with their
> functionality, if they hand off more args handling to cordova-lib
> implementations
>
> Pro's for Smarter CLI:
> - cordova-lib API's can be more "formal".  Aka node style vs string arg
> parsing / generic array/dict of args passing.
> - ..and if cordova-lib API's are more node style, easier to build better
> tools/tests for automation on top of them.
> - Generic/Dumb arg parsing may be difficult (or impossible) (Mark
> mentioned: especially with handling of optional positional arguments, but
> may be more cases).
> - ..thus current CLI interface may need to change if not all current
> command formats can be handled generically (though, change may not be bad)
>
>
>
> On Thu, Apr 17, 2014 at 5:11 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > In another thread Michal asks,
> > "How much of CLI's stay in cli: is it a *really* dumb wrapper that parses
> > input
> > in a generic fashion and turns it into dumb require() calls with opt's?
>  Or
> > does it understand the full spec and massage opts into the forms
> > cordova-lib-*
> > expect  (both options have value!)"
> >
> >
> > I like the idea of really dumb wrapper but would like to better
> understand
> > the ideas with more logic (maybe api style?) in the CLI.
> >
>

Re: CLI and cordova-lib design/extraction

[Michal Mocny <mm...@chromium.org>]

Few considerations that come to mind right away, but I have no opinions one
way or the other yet.

Pro's for Dumber CLI:
- Easier to support liberal dependency versioning (aka, don't need weekly
CLI releases as part of cordova-lib updates)
- ..as part of liberal deps, it may make it easier to supporting one global
CLI install support multiple cordova workspaces at different versions
(which has not been a terrible problem for us so far, but could be).
- Potentially easier for downstream CLI to be in-sync with their
functionality, if they hand off more args handling to cordova-lib
implementations

Pro's for Smarter CLI:
- cordova-lib API's can be more "formal".  Aka node style vs string arg
parsing / generic array/dict of args passing.
- ..and if cordova-lib API's are more node style, easier to build better
tools/tests for automation on top of them.
- Generic/Dumb arg parsing may be difficult (or impossible) (Mark
mentioned: especially with handling of optional positional arguments, but
may be more cases).
- ..thus current CLI interface may need to change if not all current
command formats can be handled generically (though, change may not be bad)



On Thu, Apr 17, 2014 at 5:11 PM, Brian LeRoux <b...@brian.io> wrote:

> In another thread Michal asks,
> "How much of CLI's stay in cli: is it a *really* dumb wrapper that parses
> input
> in a generic fashion and turns it into dumb require() calls with opt's?  Or
> does it understand the full spec and massage opts into the forms
> cordova-lib-*
> expect  (both options have value!)"
>
>
> I like the idea of really dumb wrapper but would like to better understand
> the ideas with more logic (maybe api style?) in the CLI.
>