incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: a package manager experiment
Date Mon, 15 Oct 2012 00:28:34 GMT
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
View raw message