cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram N (MS OPEN TECH)" <panar...@microsoft.com>
Subject RE: Proposal: Expose check_reqs at the CLI level
Date Wed, 15 Apr 2015 01:04:08 GMT
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:jsoref@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:panarasi@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" <csantana23@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 <jsoref@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:panarasi@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
> ><csantana23@gmail.com>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message