cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: adding platforms to npm for dependency sanity
Date Tue, 03 Jun 2014 16:19:52 GMT
Actually that was >0 LOC which is a fine argument if you ask me. And we
both know there is much more to it than just that. lazy_load…for example.

Bundling platforms is bundling a dep that we require to operate. We do not
require plugins to operate. You cannot build a project without having a
platform and, indeed, you probably want more than one.

Agree that we need discreet versioning: hence why I'm advocating we use
well understood, maintained, and effectively standard system for doing
this. We do not need NIH dependencies that is what package.json is for!




On Tue, Jun 3, 2014 at 9:07 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> On Tue, Jun 3, 2014 at 11:34 AM, Brian LeRoux <b@brian.io> wrote:
>
> > Andrew, you misunderstand. I am talking about bundling platforms directly
> > as dependencies of the CLI.
> >
> > A trivial example:
> >
> > CLI
> > '-ios
> >
> > Wherein, CLI declares the precise version of the platform it uses. We
> could
> > wildcard. I don't know that we want or need to do that.
> >
> > It would have identical semantics to today except the download penalty
> > happens up front. (We can remove lazy_load logic. We don't have to
> maintain
> > our own dependency manifests and caches. LESS code: good thing.)
> >
>
> Let me paste the code for doing our own caching for you:
>
>     cordova_npm: function lazy_load_npm(platform) {
>         if (!(platform in platforms)) {
>             return Q.reject(new Error('Cordova library "' + platform + '"
> not recognized.'));
>         }
>         var pkg = 'cordova-' + platform + '@' +
> platforms[platform].version;
>         return Q.nfcall( npm.load, {cache: path.join(util.libDirectory,
> 'npm_cache') })
>         .then(function() {
>             return Q.ninvoke(npm.commands, 'cache', ['add', pkg]);
>         }).then(function(info) {
>             var pkgDir = path.resolve(npm.cache, info.name, info.version,
> 'package');
>             return pkgDir;
>         });
>     },
>
> There's really no "amount of code" argument here.
>
>
>
> > Adding platforms at a specific version would mean having a specific
> version
> > of the CLI. Yes: this is way better! Explicit dependencies is the best
> way
> > to work w/ the small modules thing.
> >
>
> Bundling platforms with CLI would be like bundling all of the plugins with
> CLI, or like bundling every npm module with npm.
>
> Devs need to be able to try out platforms at different versions. We should
> not do anything that keeps users clinging to old versions of CLI (e.g. they
> do this now because they don't want to update to new platforms)
>
>
>
> >
> >
> >
> >
> > On Mon, Jun 2, 2014 at 7:34 PM, Michal Mocny <mmocny@chromium.org>
> wrote:
> >
> > > On Mon, Jun 2, 2014 at 10:14 PM, Andrew Grieve <agrieve@chromium.org>
> > > wrote:
> > >
> > > > Here's both flows as I understand them:
> > > >
> > > > Direct NPM flow:
> > > > # Downloads platform source into node_modules
> > > > npm install cordova-ios@3.4.0 --save
> > > > # Runs the create script and installs plugins to create platforms/ios
> > > > cordova platform add ios --path=node_modules/cordova-ios
> > > >
> > >
> > > To be fair, I think with Brian's suggestion, platform add FOO would by
> > > default look in node_modules so you wouldn't be explicit about it, and
> > also
> > > the default cordova project package.json would depend on all the latest
> > > versions of each platform, so the flows would actually be:
> > > > cordova create Foo && cd Foo
> > > > npm install
> > > > npm install cordova-ios@3.4 --save
> > > > cordova platform add android
> > > > cordova platform add ios
> > > > # crazy idea? use npm post-install hooks to auto-run create/upgrade
> so
> > > you usually don't need above two lines?
> > >
> > > Compared to:
> > > > cordova create Foo && cd Foo
> > > > cordova platform add android
> > > > cordova platform add ios@3.4
> > >
> > > I think #2 is enough better that its not worth changing.
> > >
> > >
> > > > Cordova-to-npm flow (as Mark's implemented):
> > > > # Runs "npm cache add cordova-ios", then runs create script from
> > > > ~/cache/cordova-ios/bin/create
> > > > cordova platform add ios@3.4.0
> > > >
> > > > - In both flows: we use npm to do all of the heavy lifting
> > > > - In both flows: the npm module is cached in your home directory
> > > > - In both flows?: we store the plugins & platforms explicitly within
> > > > config.xml (Gorkem's added this)
> > > > - In flow #1, we have a package.json & a node_modules, in #2 we
> don't.
> > > >
> > > > Why put the onus on the user to fetch the platform source when it's
> as
> > > easy
> > > > as running "npm cache add" under-the-hood?
> > > >
> > > >
> > > > In regards to the idea of using require() on platform scripts instead
> > of
> > > > subshelling: I think this is tangental to the debate of how to fetch
> > the
> > > > platform.
> > > > In regards to using "npm install" directly when using the plugman
> > > workflow:
> > > > Sounds good to me.
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jun 2, 2014 at 6:05 PM, Brian LeRoux <b@brian.io> wrote:
> > > >
> > > > > Eventually, yes. (Sort of how Grunt works now.)
> > > > >
> > > > >
> > > > > On Mon, Jun 2, 2014 at 5:52 PM, Terence M. Bandoian <
> > terence@tmbsw.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Can multiple versions of a platform be installed side-by-side?
> > > > > >
> > > > > > -Terence
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 6/2/2014 3:04 PM, Michal Mocny wrote:
> > > > > >
> > > > > >> >From original email: "Ideal future CLI uses platforms
just like
> > > other
> > > > > >> deps.
> > > > > >> We lose lazy loading but network and disk is cheap so it
wasn't
> > > really
> > > > > >> important anyhow."
> > > > > >> Made me think Brian is proposing adding platforms to cli
> > > package.json
> > > > > >> dependencies, and you would have a single global install
> > > > > >> cordova-platforms.
> > > > > >>   Then you can override the version with an explicit install
as
> he
> > > > > >> mentions
> > > > > >> "npm i cordova-ios@3.5.0".
> > > > > >>
> > > > > >> Personally, I think that workflow could work, and has a
few
> > > benefits,
> > > > > but
> > > > > >> I'm not sure that option compares well to the alternative
of
> just
> > > lazy
> > > > > >> loading using npm cache add as Mark has already implemented
an
> > > > > experiment
> > > > > >> (anyone interested in this topic should take a look at that
> > patch).
> > > > > >>
> > > > > >> The steps Brian & Ian outline about how to package platforms
for
> > > > release
> > > > > >> to
> > > > > >> npm are possibly an improvement over the old-style
> > platform-centric
> > > > > >> workflow.  Instead of downloading a tarball and running
a create
> > > > script,
> > > > > >> you npm install and run a create() function, and that can
more
> > > easily
> > > > be
> > > > > >> bundled into other build scripts/boilerplate.  For CLI workflow,
> > not
> > > > > sure
> > > > > >> that there is any real difference (as Jesse says).  One
note,
> > > though:
> > > > > >>   cordova-* platforms are templates for projects, so the
> > > package.json
> > > > of
> > > > > >> the
> > > > > >> npm package itself shouldn't end up inside projects that
are
> > created
> > > > > with
> > > > > >> it. I think.
> > > > > >>
> > > > > >> -Michal
> > > > > >>
> > > > > >>
> > > > > >> On Mon, Jun 2, 2014 at 3:42 PM, Ian Clelland <
> > > iclelland@chromium.org>
> > > > > >> wrote:
> > > > > >>
> > > > > >>  There seems to be some confusion -- I think people are
talking
> > > about
> > > > > >>> different things here, but perhaps it's just me ;)
> > > > > >>>
> > > > > >>> I thought that Brian's original suggestion was about
being able
> > to
> > > > host
> > > > > >>> Cordova platforms directly on NPM. That's why each one
would
> > > require
> > > > a
> > > > > >>> package.json. (which would probably end up in
> > > > > >>> <project>/platforms/<platform> in a project,
but that's not the
> > > point
> > > > > of
> > > > > >>> it).
> > > > > >>>
> > > > > >>> As an NPM project, we then would have the opportunity
(though
> not
> > > the
> > > > > >>> obligation) to make all of the supporting scripts for
each
> > platform
> > > > > >>> (create, build, run, etc) part of the node module, for
a
> uniform
> > > > > >>> interface
> > > > > >>> that doesn't require going through the command line.
> > > > > >>>
> > > > > >>> It's not about making platforms into CLI dependencies
(any more
> > > than
> > > > > >>> plugins are CLI dependencies right now), or about making
a
> > > > > cordova-based
> > > > > >>> project into a node package.
> > > > > >>>
> > > > > >>> If that's right, then I support that -- I'd like the
platforms
> to
> > > be
> > > > > >>> installable through npm, and to be versioned separately,
> > > installable
> > > > > >>> separately, and scriptable without having to spawn subshells.
> > > > > >>>
> > > > > >>> And if I have it completely wrong, then let me know
-- I'll
> just
> > go
> > > > > back
> > > > > >>> to
> > > > > >>> fixing File bugs ;)
> > > > > >>>
> > > > > >>>
> > > > > >>> On Mon, Jun 2, 2014 at 3:29 PM, Andrew Grieve <
> > > agrieve@chromium.org>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>  Not sure what your question is.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Mon, Jun 2, 2014 at 2:03 PM, Brian LeRoux <b@brian.io>
> > wrote:
> > > > > >>>>
> > > > > >>>>  *ahem
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> On Wed, May 28, 2014 at 11:20 AM, Brian LeRoux
<b@brian.io>
> > > wrote:
> > > > > >>>>>
> > > > > >>>>>  npm i cordova-ios@3.5.0
> > > > > >>>>>>
> > > > > >>>>>> Right?
> > > > > >>>>>> On May 27, 2014 11:06 PM, "Andrew Grieve"
<
> > agrieve@chromium.org
> > > >
> > > > > >>>>>>
> > > > > >>>>> wrote:
> > > > > >>>>
> > > > > >>>>> Lazy loading is what will give us the ability
to support
> > multiple
> > > > > >>>>>>>
> > > > > >>>>>> versions
> > > > > >>>>>
> > > > > >>>>>> of platforms.
> > > > > >>>>>>>
> > > > > >>>>>>> If we don't support users choosing the
version of the
> > platform
> > > > they
> > > > > >>>>>>>
> > > > > >>>>>> want,
> > > > > >>>>>
> > > > > >>>>>> then they will resist updating their version
of CLI (like
> they
> > > do
> > > > > >>>>>>>
> > > > > >>>>>> right
> > > > > >>>>
> > > > > >>>>> now).
> > > > > >>>>>>>
> > > > > >>>>>>> I'm very keen to allow users to chose
their platform
> > versions,
> > > > just
> > > > > >>>>>>>
> > > > > >>>>>> as
> > > > > >>>
> > > > > >>>> they
> > > > > >>>>>>> are able to choose their plugin versions.
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> On Tue, May 27, 2014 at 5:57 PM, Mark
Koudritsky <
> > > > > kamrik@google.com
> > > > > >>>>>>> wrote:
> > > > > >>>>>>>
> > > > > >>>>>>>  +1
> > > > > >>>>>>>>
> > > > > >>>>>>>> Steve published (some of?) the platforms
on npm as part of
> > the
> > > > > >>>>>>>>
> > > > > >>>>>>> latest
> > > > > >>>>
> > > > > >>>>> release.
> > > > > >>>>>>>> https://www.npmjs.org/package/cordova-android
> > > > > >>>>>>>> https://www.npmjs.org/package/cordova-ios
> > > > > >>>>>>>>
> > > > > >>>>>>>> CLI already require()s npm for downloading
plugins from
> the
> > > > > >>>>>>>>
> > > > > >>>>>>> registry.
> > > > > >>>>
> > > > > >>>>> Extending this to platforms is on my todo list
for this\next
> > > week.
> > > > > >>>>>>>> The "lazy" part of the loading was
about caching, so we
> > don't
> > > > lose
> > > > > >>>>>>>>
> > > > > >>>>>>> it
> > > > > >>>>
> > > > > >>>>> since
> > > > > >>>>>>>
> > > > > >>>>>>>> npm does its own caching.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Tue, May 27, 2014 at 5:42 PM,
Parashuram Narasimhan (MS
> > > OPEN
> > > > > >>>>>>>>
> > > > > >>>>>>> TECH)
> > > > > >>>>
> > > > > >>>>> <
> > > > > >>>>>
> > > > > >>>>>> panarasi@microsoft.com> wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>>  +1. This will also be a step towards
releasing platforms
> > > > > >>>>>>>>>
> > > > > >>>>>>>> independently.
> > > > > >>>>>>>
> > > > > >>>>>>>> Will the CLI have a semver like
dependency on the platform
> > > > > >>>>>>>>>
> > > > > >>>>>>>> specified
> > > > > >>>>
> > > > > >>>>> somewhere ? Would the cli have to require('npm')
and do the
> > > > > >>>>>>>>>
> > > > > >>>>>>>> install?
> > > > > >>>>
> > > > > >>>>> -----Original Message-----
> > > > > >>>>>>>>> From: brian.leroux@gmail.com
[mailto:
> > brian.leroux@gmail.com]
> > > > On
> > > > > >>>>>>>>>
> > > > > >>>>>>>> Behalf
> > > > > >>>>>>>
> > > > > >>>>>>>> Of
> > > > > >>>>>>>>
> > > > > >>>>>>>>> Brian LeRoux
> > > > > >>>>>>>>> Sent: Tuesday, May 27, 2014
2:20 PM
> > > > > >>>>>>>>> To: dev@cordova.apache.org
> > > > > >>>>>>>>> Subject: adding platforms to
npm for dependency sanity
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> We've discussed this but I'm
not sure the whole idea has
> > > > > >>>>>>>>>
> > > > > >>>>>>>> crystalized.
> > > > > >>>>>
> > > > > >>>>>> My
> > > > > >>>>>>>
> > > > > >>>>>>>> proposal (based on previous discussions)
below. I'll use
> iOS
> > > as
> > > > > >>>>>>>>>
> > > > > >>>>>>>> an
> > > > > >>>
> > > > > >>>> example
> > > > > >>>>>>>>
> > > > > >>>>>>>>> but this applies to all platforms
supported by the CLI.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> First, we'd add two files:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> cordova-ios
> > > > > >>>>>>>>> |-package.json
> > > > > >>>>>>>>> '-index.js
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> …I don't think I need to describe
the utility of
> > package.json
> > > > > >>>>>>>>>
> > > > > >>>>>>>> but
> > > > > >>>
> > > > > >>>> index.js
> > > > > >>>>>>>>
> > > > > >>>>>>>>> would expose programatic library
apis:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> module.exports = { create:Function,
run:Function,
> > > > > >>>>>>>>>
> > > > > >>>>>>>> build:Function,
> > > > > >>>
> > > > > >>>> clean:Function, log:Function}
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> We then publish to npm. That
is it for now. Ideal future
> > CLI
> > > > > >>>>>>>>>
> > > > > >>>>>>>> uses
> > > > > >>>
> > > > > >>>> platforms just like other deps. We lose lazy loading
but
> network
> > > > > >>>>>>>>>
> > > > > >>>>>>>> and
> > > > > >>>>
> > > > > >>>>> disk
> > > > > >>>>>>>
> > > > > >>>>>>>> is cheap so it wasn't really important
anyhow.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Discuss!
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >
> > > > >
> > > >
> > >
> >
>

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