cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: adding platforms to npm for dependency sanity
Date Tue, 03 Jun 2014 17:17:39 GMT
On Tue, Jun 3, 2014 at 12:19 PM, Brian LeRoux <b@brian.io> wrote:

> 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.


If you're concerned about code, there is a tonne of much lower-hanging
fruit.


>
> 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.
>
I don't require blackberry to create an iOS project. But I do require some
plugins. We use "npm cache add" to download plugins, I don't see how
platforms would not work just as easily.


>
> 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!
>

I don't know what NIH dependencies are. Googling suggests you're talking
about drugs...

We *are* using npm for downloading, we're just not making the user type it
directly.

Mark's approach also avoids the "what-if" cases where what's in your
node_modules might not match what's in your platforms/

Does what Mark has implemented not address a use-case of yours? Or are we
going back & forth over personal preference?






>
>
>
>
> 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