Hi Vladimir,
It's great to see this being worked on and discussed. My comments below are
mine and mine alone.
In addition to the code changes, I would have preferred to see a specification
of the command, e.g.
cordova check-reqs platform [platform...]
I took a quick look at the CLI code changes and didn't see any option
processing. Are there any options?
Do the platform(s) specified on the command need to have been already added to
the project?
Does the command require a project - i.e. be executed in a project directory?
Regarding the command name, I don't think being 'cute' is helpful to users -
i.e. I recommend against 'doctor'.
I think 'check-requirements' would be OK. It's long but how many times does a
user need to type it?
Thanks,
Leo
-----Original Message-----
From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
Sent: Wednesday, April 22, 2015 7:18 AM
To: dev@cordova.apache.org
Subject: RE: Proposal: Expose check_reqs at the CLI level
Hey, guys. Have anyone looked at it?
I've made some refactoring to make changes more readable, and updated data
contract between platform's check_reqs code and LIB API.
Josh, regarding command name. I thought that there is still no agreement about
verb name.
Personally I agree that `cordova doctor` or `cordova requirements` sounds
better, but this is just a command name ant it could be changed at any time.
---------------
Best regards, Vladimir
-----Original Message-----
From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
Sent: Monday, 20 April, 2015 22:04
To: dev@cordova.apache.org
Subject: RE: Proposal: Expose check_reqs at the CLI level
This was only an initial implementation - no pull request has been sent. I
think this is just a way for folks to play with what Vlad has now. I am sure we
will change the verb name before a PR comes in.
-----Original Message-----
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Monday, April 20, 2015 11:59 AM
To: dev@cordova.apache.org
Subject: RE: Proposal: Expose check_reqs at the CLI level
-1
Didn't everyone agree to call it `cordova doctor` or worst, `cordova
requirements`?
> -----Original Message-----
> From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
> Sent: Monday, April 20, 2015 11:46 AM
> To: dev@cordova.apache.org
> Subject: RE: Proposal: Expose check_reqs at the CLI level
>
> 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
> KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> KKKKKKKKKKCB [ X ܚX KK[XZ[
> ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ ]
> Z[ ܙݘK \X K ܙ B
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
