cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Proposal: Expose check_reqs at the CLI level
Date Wed, 15 Apr 2015 14:59:46 GMT
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.treggiari@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:panarasi@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: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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message