Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of csantana23@gmail.com designates
 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANpVHHxbLi6+dT87xi5OsULS6WurUw3h8yHUVpMkmNVz8ua+hA@mail.gmail.com>
References: 
 <CABiQX1V9=B9O8=6Aqa8uw1v5_ND91SuChtXRQBivWQU4G=0Gbg@mail.gmail.com>
	<CA+X37cmfHHkqZG6jgfisabOJwd6pZ7n1q4gjv97GZ5KfQDx9hw@mail.gmail.com>
	<CAMTxO40gY6hRLpHrmvHQPkAuJ-UN9gAhcTVLHKcu=ie7yLWohw@mail.gmail.com>
	<CAMk5LLmxXhwiz7wGT_kKR6joNzEznrxA-SbXb-aquPO2DWWLWw@mail.gmail.com>
	<CANpVHHxbLi6+dT87xi5OsULS6WurUw3h8yHUVpMkmNVz8ua+hA@mail.gmail.com>
Date: Fri, 14 Mar 2014 23:36:41 -0400
Message-ID: 
 <CAHYtTqmD1U0CDTr+foXy0mbp3v_55Eqy8kzjkGEn3F2Sf2uPNA@mail.gmail.com>
Subject: Re: Consolidating the Distribution of Platforms & Plugins
From: Carlos Santana <csantana23@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c37e8e0b41aa04f49ce54c

--001a11c37e8e0b41aa04f49ce54c
Content-Type: text/plain; charset=ISO-8859-1

I have being thinking on this sort of problem also.

I think using npm to store none node code is perfectly fine use case.

I vote to leverage npm as the building block and then build cordova
functions on top of it.

If we need to download something from the web use npm (leverages user's
already configuration on reaching the inner web i.e. proxy, https/http,
etc..)
Leverage npm cache implementation.

Also one big thing is resolving dependencies, maybe we can use npm to
resolve plugin and platform versions for a particular App.

I think it would be neat if I can have a package.json with the dependencies
section containing the list of platforms and plugins for my App.

On top of it maybe have cordova could parse package.json and automate the
creating of the app
$cordova install
Running npm install...
Processing pacakge.json...
Installing platforms...
Installing plugins...


"dependencies": {
   "org.apache.cordova.platform.ios": ">=3.4.0",
   "org.cordova.platform.android": ">=3.3.0",
   "org.apache.cordova.device": "~0.2.8",
   "cordova-cli": "~3.4.0"
},
"scripts": {
   "postinstall":"./node_modules/.bin/cordova create app --link-to=.;
./node_modules/.bin/cordova platform add ios
--path=../node_modules/org.apache.cordova.platform.ios/",
}
"engines": {
    "cordova":">=3.4.0"
}

It's all fresh in my mind, so maybe it can be a Cordova 4.x CLI story :-)

I think using npm doesn't block us from having a web site to find plugins
and platforms and collect download stats

--Carlos


On Fri, Mar 14, 2014 at 3:00 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> On Fri, Mar 14, 2014 at 7:13 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Cordova platforms don't map into Cordova plugins very well at all.
> >
>
> No, they don't indeed. It would be really interesting to `plugin add` a
> platform.
>
>
> >
> > For npm modules, we can specify arbitrary sources, but npm has its own
> > ideas about where things should be installed. Do we actually want the
> > platforms, or at least their templates, to live in node_modules? I
> suppose
> > that's a reasonable flow.
> >
> > 1. Lazy load. Formerly via git into a cache dir in $HOME, now via npm
> into
> > $PROJECT/node_modules/cordova-foo.
> > 2. Same as before: Run the platform's bin/create script to install an
> > instance of the platform in $PROJECT/platforms/foo.
> >
> > That should be drop-in-able. But I don't know how well our collections of
> > non-JS files will fit into npm. It's not really intended for this sort of
> > thing.
> >
>
> Yes, that is why I like this solution. We also remove our dependency on git
> for CLI.
>
> There are a lot of non javascript-only modules on NPM. Some Javascript
> modules rely on native components (usually built with node-gyp). We
> wouldn't need to do that as we would be be basically using npm as a storage
> solution alternative to git. We also still get to keep to ability to
> version platforms (as opposed to tags etc...).
>
> As a side note, I've published cordova-js to npm as well because I need it
> for my current browserify efforts. I will explain why in another thread.
>
>
> >
> > Braden
> >
> >
> > On Fri, Mar 14, 2014 at 9:19 AM, David Kemp <drkemp@chromium.org> wrote:
> >
> > > +1 to handling both the same way and not using git for distribution.
> > >
> > > I'm interested in the pros and cons of using the plugin registry vs
> npm.
> > >
> > >
> > >
> > > On Thu, Mar 13, 2014 at 10:14 PM, Gorkem Ercan <gorkem.ercan@gmail.com
> > > >wrote:
> > >
> > > > Great idea..  I especially don't like the git archive download. It
> does
> > > not
> > > > really allow us to track some sort of statistics reliably. I think
> its
> > > > replacement should allow collection of download statistics. The
> plugins
> > > > stats from plugman seems OK. I am not sure if npm would allow such
> > stats.
> > > >
> > > > Not that important to this discussion but I think plugman has a cache
> > in
> > > > .plugman/cache
> > > >
> > > > --
> > > > Gorkem
> > > >
> > > >
> > > > On Thu, Mar 13, 2014 at 11:25 AM, Andrew Grieve <
> agrieve@chromium.org
> > > > >wrote:
> > > >
> > > > > Right now, CLI downloads & caches platforms & plugins using two
> > > different
> > > > > mechanisms, with totally independent code paths.
> > > > >
> > > > > plugman uses the request library, with proxy settings in
> > > .plugman/config.
> > > > > It downloads the tars directly from registry.cordova.io. It does
> not
> > > > cache
> > > > > them.
> > > > >
> > > > > CLI uses the request library as well, with proxy settings from
> > .npmrc.
> > > It
> > > > > downloads tars directly from our git server's archive endpoint. It
> > > caches
> > > > > them in ~/.cordova.
> > > > >
> > > > >
> > > > > I'd like to propose that we unify them. Specifically:
> > > > >
> > > > > 1. Store platforms on registry.cordova.io
> > > > >   - This would allow CLI to easily see what versions of platforms
> are
> > > > > available, and be able to choose between them.
> > > > >   - This (I'm sure), INFRA would be much happier about than our
> > current
> > > > > fetch-from-git approach
> > > > >
> > > > > 2. Unify CLI & Plugman's downloading logic
> > > > >   - Use the same code-path for both.
> > > > >   - Have them use the same caching logic.
> > > > >
> > > > > 3. Use npm's cache logic instead of our own:
> > > > >   - Just type npm help cache to see what it does
> > > > >   - Would allow for: "cordova cache clean"
> > > > >
> > > > > I would *not* want to lose our support for --searchpath, as I think
> > > it's
> > > > > really handy. I don't see a problem with this though.
> > > > >
> > > > > This would also enable CLI to answer queries like "what platform
> > > versions
> > > > > are available", and make it trivial to do "install
> > > cordova-android@3.0.0
> > > > "
> > > > >
> > > > > This isn't something I have time to work on in the near future, but
> > > > wanted
> > > > > to see if everyone would be onboard with the change. I'll end up
> just
> > > > > filing bugs for the changes if it sounds good... but if anyone else
> > > wants
> > > > > to work on it... :)
> > > > >
> > > >
> > >
> >
>


-- 
Carlos Santana
<csantana23@gmail.com>

--001a11c37e8e0b41aa04f49ce54c--