Hi, list.

I would like to share a draft implementation for check_reqs command and 
check_reqs API: 
Changes  could be found here:
    CLI: 
https://github.com/apache/cordova-cli/compare/master...MSOpenTech:requirements_check
 
    LIB: 
https://github.com/apache/cordova-lib/compare/master...MSOpenTech:requirements_check
 
    Cordova-android: 
https://github.com/apache/cordova-android/compare/master...MSOpenTech:requirements_check
 

The implementation consists of following:
1. 'cordova check-reqs' command for cordova CLI, which calls corresponding 
cordova-lib API with options, specified from CLI

2. 'check_reqs' module for cordova-lib, which works as a wrapper around 
platforms' check_reqs scripts. It returns a promise, either resolved if 
check_reqs platform script is found and ran successfully or rejected in case if 
check_reqs script is failed due to some internal errors or not found at all.

3. check_reqs script for android platform, updated to return array of 
requirements.

    * Each requirements is an object with following fields: 
        - id - some short id, could be useful for tools, that consume API 
directly
        - name - readable name for this requirement, such as 'Jav JDK' or 
'Gradle build tools', etc.
        - installed - Boolean paremeter that indicates if requirement is 
properly installed/satisfied
        - reason - error, reported by requirements check routines if 
requirement is missing.

Please note that work is still in progress, and will be changed according to 
review comments.
TBD:
    * move presentation logic from LIB to CLI;
    * refine data format, returned by cordova-lib API
    * add other platforms
    * and more... :)

---------------
Best regards, Vladimir

-----Original Message-----
From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] 
Sent: Monday, 20 April, 2015 3:49
To: dev@cordova.apache.org
Subject: RE: Proposal: Expose check_reqs at the CLI level

Looks like implementing a global level check_reqs without a project seems 
harder, I would suggest we make it a part of a second phase of this 
implementation. For now, we have a basic version that simply abstracts out 
existing check_reqs into a separate, platform level command. This could be a 
good first phase, and should also give us an idea about how developers use this 
command.

As a part of Phase 2, anyone from the community should be able to build on a 
cordova level check reqs, and possibly extend it to checking reqs when no 
project is present. 


-----Original Message-----
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Wednesday, April 15, 2015 8:53 AM
To: dev@cordova.apache.org
Subject: RE: Proposal: Expose check_reqs at the CLI level

We already support:

`cordova build android`

There's no need for the extra `platform` verb..

But,
`cordova build android --nobuild` isn't any more intuitive than w/ the extra 
"platform".


And yes, as I noted, and others have noted, we used to run check_reqs in add, 
we're not going back to doing that.

A `cordova doctor` or `cordova requirements` verb seems fine.

I'm also fine `cordova doctor PLATFORM` instead of `cordova platform doctor 
PLATFORM`,

As for when someone is likely to want to ask "what requirements do I need for 
a platform", it's fairly arbitrary.

Someone who is given a project might know that they don't have the environment 
for a platform, they aren't likely to want to go down a "build" rabbit hole, 
so, I'm -1 on hiding it anywhere near build.

It's perfectly reasonable from my perspective for someone to want to run 
`cordova requirements PLATFORM` without a project at all.
Imagine someone is getting started, they "install cordova", and know they want 
to develop for PLATFORM, they could reasonably want to set up their 
requirements for that platform before trying to create a project...

I don't know if anyone's check_reqs scripts actually requires a project, I 
actually think they don't, so it's probably sufficient to run them straight 
from the platform origin instead of from a created project.

One notable thing: check_reqs isn't a .js file yet, as an API, it's 
"check_reqs" (*nix) and "check_reqs" + something from %PATHEXT% (Windows)

> -----Original Message-----
> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
> Andrew Grieve
> Sent: Wednesday, April 15, 2015 11:00 AM
> To: dev
> Subject: Re: Proposal: Expose check_reqs at the CLI level
>
> We've worked to make iOS add'able from Windows, so I do think it's a good
> idea to *not* run check_reqs from add (we used to but removed it).
>
> We already run it on build, so potentially we already have this command:
> "cordova platform build android --nobuild"
>
>
>
> On Tue, Apr 14, 2015 at 9:51 PM, Treggiari, Leo <leo.treggi...@intel.com>
> wrote:
>
> > My opinions.
> >
> > Q1.  Just say that platform is not added, so cannot check requirements.
> >
> > I don't think it is important to support the platform-not-added case.
> >
> > Q2.  Should the requirements be checked when a platform is added, or
> when
> > it is built ?
> >
> > 'platform add' should work even when the requirements are not met.  If
> > requirements
> > used to be checked on 'platform add', then I suspect they were removed to
> > support
> > the scenario of using the same Cordova project on multiple host platforms.
> > E.g. a team with some developers on Windows and some on Mac.  As a user
> of
> > Cordova CLI on Windows, I want it to be OK to have the project I'm working
> > on have the
> > iOS platform added and I only get errors if I try to do something (build,
> > emulate)
> > which requires the native SDK.
> >
> > Leo
> >
> > -----Original Message-----
> > From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
> > Sent: Tuesday, April 14, 2015 6:04 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: Expose check_reqs at the CLI level
> >
> > I think you raise an interesting point on the behavior of check_reqs for
> > platform that are not yet added.
> >
> > The options, as you mention are
> >
> > Question 1
> > 1 -  Add the platform, run check_reqs script, remove the platform and
> > report results.
> > 1.5 - Just download the check_reqs script (or use it from the cached
> > platform directory) without adding the platform, and run that.
> > 2 -  Just say that platform is not added, so cannot check requirements.
> >
> > Question 2: It also comes to the case of - when would a user want to run
> > the requirement check
> > - before starting a cordova project ?
> > - before adding a platform ?
> > - should the requirements be checked when a platform is added, or when it
> > is built ?
> >
> > The answer to the above questions will help us understand if a top level
> > req_check is required or not. We should also look at what check_reqs do
> > today - the do not tell you ALL the missing pieces for building an SDK.
> >
> > It would be good to hear what the others in the community think about
> > these answers.
> >
> > -----Original Message-----
> > From: Josh Soref [mailto:jso...@blackberry.com]
> > Sent: Tuesday, April 14, 2015 9:55 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: Expose check_reqs at the CLI level
> >
> > Fwiw, for the case of a platform that isn't in a project yet, I'd 
> > envision:
> >
> > `cordova platform doctor not-yet-installed`
> >
> > to do effectively:
> > ```sh
> > (
> > PLATFORM=not-yet-installed
> > (cordova platform add $PLATFORM 2>&1) > /dev/null &&
> > cordova platform doctor $PLATFORM;
> > (cordova platform remove $PLATFORM 2>&1)
> > )
> > ```
> >
> > i.e. add the platform (or create a temporary project, and add the platform
> > to the temporary project), and then run platform doctor, and then remove
> > the
> > platform (and if it was in a temporary project, delete the temporary
> > project...).
> >
> > I don't really want to expos a 'check_reqs' verb via CLI.
> >
> > If we really really want to, we could have `cordova platform requirements
> > [PLATFORM...]` as a verb, that's ok.
> >
> > If someone wants to call `check_reqs` directly, they're welcome to do so,
> > but it's an incredibly ugly thing and doesn't belong in a public facing
> > interface.
> >
> >
> > > -----Original Message-----
> > > From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
> > > Sent: Tuesday, April 14, 2015 10:19 AM
> > > To: dev@cordova.apache.org
> > > Subject: Re: Proposal: Expose check_reqs at the CLI level
> > >
> > > Carlos, you are right, check_reqs should be in the platform repo, CLI
> > will
> > > just proxy the call to the platforms.
> > >
> > > On 4/13/15, 10:29 PM, "Carlos Santana" <csantan...@gmail.com> wrote:
> > >
> > > >+1 if check_reqs are kept in the platform repos, currently check_reqs 
> > > >is
> > a
> > > >platform concerned
> > > >if it's available from CLI it will be just a proxy to the platform
> > > >check_reqs.
> > > >
> > > >if don't keep it in the platform repo, and add this logic to cli repo,
> > we
> > > >will need to maintained a list of reqs for each platform, for each
> > version
> > > >of each platform.
> > > >
> > > >This is the reason why it was removed from cli and just is present in
> > the
> > > >platform repo/code
> > > >
> > > >
> > > >
> > > >On Mon, Apr 13, 2015 at 5:13 PM, Josh Soref <jso...@blackberry.com>
> > > wrote:
> > > >
> > > >> I'm +1 for `cordova doctor` and `cordova platform doctor
> > > >>{platformname}`.
> > > >>
> > > >> The former should apply to all current platforms, the latter should
> > > >>support
> > > >> doctoring for available but not added platforms -- if said platform
> > were
> > > >> specified.
> > > >> And we should note in the documentation or `cordova doctor` that it
> > may
> > > >>do
> > > >> other checks -- e.g. linting the config.xml, warning about CSP,
> > possibly
> > > >> mentioning when a plugin is out of date -- just to indicate to people
> > > >>that
> > > >> the behavior may evolve.
> > > >>
> > > >> Not that this is more or less fixing a regression that we introduced
> > > >>when
> > > >> we
> > > >> made `cordova platform add` not call check_reqs.
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: Parashuram N (MS OPEN TECH)
> [mailto:panar...@microsoft.com]
> > > >> > Sent: Monday, April 13, 2015 2:53 PM
> > > >> > To: dev@cordova.apache.org
> > > >> > Subject: Proposal: Expose check_reqs at the CLI level
> > > >> >
> > > >> > Hi,
> > > >> >
> > > >> > One of the main problems a lot of developers seem to have is the
> > > >>issue to
> > > >> > setting up their machines for building various platforms. This came
> > > >>out
> > > >> from
> > > >> > the Stack overflow survey, and the number of questions on stack
> > > >>overflow,
> > > >> > twitter. Etc.
> > > >> >
> > > >> > I thought it would be helpful to have a check_reqs command
> exposed
> > at
> > > >>the
> > > >> > CLI level. This is similar to `brew doctor` or `appium doctor`. The
> > > >>idea
> > > >> is
> > > >> >
> > > >> >
> > > >> > 1.       Have a way for the user to see if they have all
> > dependencies
> > > >> (like
> > > >> > JAVA_HOME or ANDROID_HOME) set up? This happens at build time,
> but
> > > >> > moving it out to a CLI level command where you can run cordova
> > > >>check_reqs
> > > >> > (or something similar) would be useful to the users.
> > > >> >
> > > >> > 2.       Today, the build command shows one error at a time. The
> > > >> check_reqs
> > > >> > could run all the checks, and show a summary of the issues so that
> > the
> > > >> user
> > > >> > can fix them all, instead of fixing one, running build, fixing
> > again,
> > > >> etc.
> > > >> >
> > > >> > What does the community think of this idea ? Can we implement a
> > > >>prototype
> > > >> > and see if this is useful to our developers ?
> > > >> > Note that this does not change or break existing functionality - it
> > > >>just
> > > >> exposes
> > > >> > the already existing check_reqs in the CLI. Build will continue to
> > > >>call
> > > >> > check_reqs.
> > > >> >
> > > >> > Please vote on this proposal, or raise any concerns you may have.
> > > >>
> > > >
> > > >
> > > >
> > > >--
> > > >Carlos Santana
> > > ><csantan...@gmail.com>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB  [  
X  ܚX KK[XZ[
 ] ][  X  ܚX P ܙݘK \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[ ܙݘK \X K ܙ B

Reply via email to