incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: a package manager experiment
Date Mon, 15 Oct 2012 00:44:39 GMT
> there's a lot of stuff going on in that link.
certainly, happy to do that:

   - would cordova specific code blobs being packaged as npm modules
   pollute npm? an illustrative scenario: I go on npmjs.org right now and
   browse the packages. It's like xmas; I see all these awesome modules that I
   can use in any node app that I build. Fast foward to a future where
   hundreds of cordova plugins are in npm. Joe user is browsing packages to
   pull into his super awesome node based app. He's never heard of cordova or
   doesnt use it. He keeps running into these modules that reference cordova,
   and are utterly useless by themselves, because its meant to work with this
   whole other platform. Suddenly there are modules in npm that have nothing
   to do with writing packages that work in the node ecosystem. These modules
   arent truly modules because they dont expose an API that makes it re-usable
   as an atomic unit of code.
   - plugins are intrinsically tied to specific development platforms and
   SDKs. Is there a way in npm to say "this module depends on Android SDK
   0.3.x, 0.4.2, and cordova 0.2.x ? There's been talk in our mailing list of
   using the engines tag in package.json but I'm under the impression that
   it's soon to be deprecated.
   - the install process for one of these plugins is very different from a
   typical npm module. the install code has a bunch of logic to move the bits
   of each plugin into the build environment in existing projects in xcode
   ios, android projects, etc. Not sure if npm provides some kind of install
   hooks to modify this behavior, I would assume its rigidly following
   node_modules as the destination for all installed modules.
   - without going too much into cordova plugin internals, the package file
   for a cordova plugin is an XML file (aptly named plugin.xml.) We've
   considered JSON vs XML for the plugin's manifest format, but because many
   of the install steps involve grafting/pruning XML tags in configuration
   files, JSON seems like a poor way to represent these chunks of xml to
   operate on. So if we use npm's package.json, we'd need to maintain that,
   and the plugin.xml. Maybe there is an elegant way to store XML blocks in
   JSON, which means we could do away with using XML as our main format, but
   it's unclear to me at this point the best course of action. having to
   maintain some data that is identical between package.json and plugin.xml
   just feels bad, bad, bad.
   - cordova plugins ideally have a form of plugin resolution at the
   publish step. So for example in the NFC plugin, it should have a unique
   java package style identifier likeio.cordova.nearfieldcomm The registry
   should be able to detect this, and enforce uniqueness to prevent collisions
   with other plugins.
   - There are other forms of collisions that would be checked for. e.g,
   when building plugins for the ios platform, classnames exists in the same
   namespace, so there should be a way to ensure classnames aren't colliding.

> we've been discussing pkg mgmt for 3 years
I understand the sense of urgency; I'm sure after a while it's like "f* it
let's just build something". :) I'm not suggesting we launch into a 6 month
academic discussion of perfect plugin distribution. I think with a few days
of back and forth we were really productive on pluginstall and it's lower
level pieces, and got some really great changes into a common place. I'm
hoping for similar results here. :)


-Mike


On Sun, Oct 14, 2012 at 8:28 PM, Brian LeRoux <b@brian.io> wrote:

> Eh mike, could you just briefly write out the bullets? ....there's a
> lot of stuff going on in that link. =)
>
> FWIW, we've been discussing pkg mgmt for 3 years which may be why most
> of us lean to prototyping fast at this point. I feel node/issac has
> solved the issue best of all the solutions I've personally
> investigated and happy to comment specifically on any concerns you
> have.
>
>
> On Sun, Oct 14, 2012 at 5:17 PM, Mike Reinstein
> <reinstein.mike@gmail.com> wrote:
> > What I'm worried about is trying to do a top-down design on a package
> > manager without looking at the underpinnings.  I really don't care _how_
> > the problems are solved. I don't think my registry toy solves the issues,
> > nor does the solely npm based solution. It's  a big mistake to
> definitively
> > choose how we should package and distribute plugins without discussing
> the
> > issues we've identified at a low level.
> >
> > The issues that I've brought up are in the bullets in this post:
> > https://github.com/dominictarr/rc/issues/5
> >
> > Does anyone have feedback on these?
> >
> > -Mike
> >
> >
> > On Sun, Oct 14, 2012 at 7:58 PM, Brian LeRoux <b@brian.io> wrote:
> >
> >> I'm in the 'reuse npm as a dependency' camp. We can override stuff
> >> that way and not get stuck re-implementing the entire thing.
> >>
> >> Just look at the size of Max's proposal as a result.Less code to
> >> write, means less to test, and ultimately less to maintain.
> >>
> >> That said, I encourage we code for all the things and see what suites us
> >> best.
> >>
> >>
> >> On Sun, Oct 14, 2012 at 12:11 PM, Mike Reinstein
> >> <reinstein.mike@gmail.com> wrote:
> >> > Hi Max!
> >> >
> >> > We've been chatting about package manager stuff a bit prior to your
> >> arrival
> >> > a few days ago. The 2 main proposals we've seen are to use npm for
> >> > everything, or try to set up an independant system, which is similar
> but
> >> > different (hopefully suited to cordova's particulars.) I've been
> >> exploring
> >> > option 2, and had a brief discussion with Isaac Schlueter and Dominic
> >> about
> >> > this. I think it's an interesting read.
> >> > https://github.com/dominictarr/rc/issues/5
> >> >
> >> > Here is the spec (and partial implementation) of what I've got so far:
> >> > https://github.com/mreinstein/cpm
> >> >
> >> > I would really appreciate some feedback on this. If it turns out that
> the
> >> > cordova community is really against doing it this way then I'd rather
> >> know
> >> > sooner than later, so I'm not burning time on a project that no one
> >> wants.
> >> > I'm hoping for more feedback from Isaac as well, especially on the
> >> bullets
> >> > in that rc discussion because I think I outlined all the major hurdles
> >> that
> >> > using npm straight up might introduce. In my opinion, using npm
> directly
> >> > would be a mistake, but I'm still in the experimentation phase at this
> >> > point.
> >> >
> >> > -Mike
> >> >
> >> >
> >> > On Sun, Oct 14, 2012 at 8:27 AM, Max Ogden <max@maxogden.com> wrote:
> >> >
> >> >> meet lunny
> >> >>
> >> >> https://github.com/maxogden/lunny
> >> >>
> >> >> lunny is about 60 lines of code:
> >> >> https://github.com/maxogden/lunny/blob/master/lib/lunny.js
> >> >>
> >> >> the basic idea is:
> >> >>
> >> >> 1. use npm for pretty much everything
> >> >> 2. if a package has some special metadata in its package.json then
> lunny
> >> >> will run plugin-install with the proper arguments
> >> >> 3. there is no step 3!
> >> >>
> >> >> right now the hardest part about publishing and distributing a
> cordova
> >> >> package is authoring the plugin.xml file so I have only tested this
> with
> >> >> the childbrowser plugin from http://github.com/alunny/childbrowser
> >> >>
> >> >> thoughts welcome!
> >> >>
> >>
>

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