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
smime.p7s
Description: S/MIME cryptographic signature
