cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Mapping plugin ID -> URL
Date Thu, 03 Oct 2013 20:57:27 GMT
@Michal SGTM. The original approach has some other benefits on top of
the current requirements. However, I don't know if we need those
benefits just yet.

On Thu, Oct 3, 2013 at 6:06 PM, Carlos Santana <csantana23@gmail.com> wrote:
> I think plugman is trying to do more than it should.
> We should look into something like bower to handle dependencies and
> fetching them to a local folder for a project.
> Bower can be use by user via cli and plugman can use it as a node library.
>
> Bower handles the download of packages/repo with it's versions/tags to a
> local folder.
> I see a cordova plugin be analogous and not that different from a package.
>
> Then plugman uses a local folder (bower_components, cordova_components,
> or what ever name) to install plugins from that folder.
>
> Cache only solved the problem of network usage, it doesn't solve
> portability of a project/repo.
>
> I'm out on vacation but wanted to bring up Bower for front-end
> dependencies. We can leverage their lessons learned or their code and we
> don't have to re-invent the wheel.
>
> TLDR: I vote for plugman to have an option for install command to skip the
> registry and use local folder already populated with a set of plugins.
>
> -- Carlos
>
>
> On Thursday, October 3, 2013, Michal Mocny wrote:
>
>> On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny <mmocny@chromium.org<javascript:;>>
>> wrote:
>>
>> >
>> >
>> >
>> > On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <anis.kadri@gmail.com<javascript:;>>
>> wrote:
>> >
>> >> Braden and I have talked about it in the past but there is already a
>> >> $HOME/.plugman/cache and plugman will not attempt to fetch plugins if
>> >> they are already in the cache. Unless I am missing something can you
>> >> just not drop your dependencies in there?
>> >>
>> >
>> > This sounds like it would work, but I'm hesitant to force a global
>> > installation of the cache.  I think it would mean you cannot develop BB
>> > webworks apps on the same machine as you develop vanilla cordova apps
>> since
>> > the same plugin id would map to different places across *all* plugman
>> using
>> > projects.
>> >
>> > Note that it already has been a source of problems to have things
>> > needlessly added to ~/.cordova and ~/.plugman.
>> >
>>
>> Thinking about this more, I think using the global cache is subtly
>> different than what we want here.  However, I think we could perhaps
>> leverage the concept and share most of the code.  Here is the big
>> difference:
>>
>> - The global plugman cache is used *after* going out to registry to lookup
>> latest version, so as not to download the same plugin version multiple
>> times.
>> - This proposed local search path is to be used *before* going out to
>> registry, without caring about its content or version number.
>>
>> Perhaps the current behaviour can be decomposed into two steps: (1) "update
>> global cache with newest plugin version via registry" and (2) "install
>> plugin from cache".  Then, installing a plugin by ID could be:
>>
>> - Attempt Step (2) from local search path(s)
>> - then, if above failed, do Step (1)
>> - then, if above succeeded, Attempt Step (2) from global cache
>>
>> How does that sound?
>>
>>
>> >
>> >>
>> >> Are there other use cases than simply 'not fetching from registry and
>> >> using local path' for a given plugin ID ?
>> >>
>> >
>> > I think this is the only use case we are looking to solve, but it shows
>> up
>> > in different situations: during cordova plugin add ID or plugman
>> --install
>> > with <dependancy> etc.
>> >
>> >
>> >>
>> >> #1 and #2 can be solutions to some problems but do we have those
>> >> problems yet ? They can be a solution to managing multiple registry
>> >> sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...)
>> >> because right now we only support.
>> >>
>> >
>> > Yes, we already do have these problems, as said: IBM, BB, and to some
>> > extent Mobile-Chrome-Apps is already needing this solution.
>>  Implementing a
>> > new registry would be fine, if it worked offline for local-only installs,
>> > preferably without the need to set up a server/couchdb for such simple
>> > local only mappings, which is exactly Andrews proposal.
>> >
>> >
>> >>
>> >> Your proposed changes also seem to only affect CLI since you mentioned
>> >> a ".cordova/config.json". plugman only users would potentially be
>> >> penalized once again.
>> >>
>> >
>> > I completely agree this is implemented in plugman.  We are discussing CLI
>> > just to establish the convention for how to store the cache, but plugman
>> > would have all the underlying functionality.  It *has* to be this way,
>> > since its the one that resolves dependencies, and will need a new
>> argument
>> > alongside --install to know where to lookup id for local mapping.
>> >
>> >
>> >>
>> >> On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny <mmocny@chromium.org>
>> wrote:
>> >> > I think the missing piece is that the plugin author has the option
of
>> >> > specifying dependencies in terms exactly *one* of these options:
>> >> >
>> >> > (a) id, to be looked up in the registry
>> >> > (b) explicit git url
>> >> > (c) relative path
>> >> >
>> >> > The problem is that a downstream *distributor* cannot override these
>> >> values
>> >> > at the moment, without making direct edits to the plugin.xml.  e.g.
>> IBM
>> >> and
>> >> > BlackBerry have already both spoken up about the problem of shipping
a
>> >> > cordova based tool with plugins bundled, and having full control over
>> >> > plugin versions, supporting offline work, etc.
>> >> >
>> >> > How can we solve the generic case of using the CLI with the registry,
>> >> while
>> >> > supporting the bundling/tarball use case?
>> >> >
>> >> > Andrews proposal would allow for option (a) to be overwritten by a
>> >> > distributor without changes to the plugin.xml, by implementing a local
>> >> > workspace mapping of id -> path, which is used by cli instead of
>> >> reaching
>> >> > out to the registry (though it could still use the registry for id's
>> >> that
>> >> > are not in the mapping).
>> >> >
>> >> > I suspect it would also make (a) the only necessary way to specify
>> >> plugin
>> >> > dependencies in practice, which I think is a win for simplicity.
>>  Thats
>> >> my
>> >> > understanding anyway.
>> >> >
>> >> > -Michal
>> >> >
>> >> >
>> >> > On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b@brian.io> wrote:
>> >> >
>> >> >> Well, not npm but rather http://plugins.cordova.io or by URL or
by
>> >> >> relative
>> >> >> path (allowing for vendored plugins). That is how Node does it
TMK
>> and
>> >> >> should cover our use cases too without adding new config file options
>> >> (or
>> >> >> worse more config files).
>> >> >>
>> >> >> Am I missing something?
>> >> >>
>> >> >>
>> >> >> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <agrieve@chromium.org>
>> >> >> wrote:
>> >> >>
>> >> >> > Could you give an example of how you'd use npm or vendor
>> >> dependencies?
>> >> >> >
>> >> >> >
>> >> >>
>
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>

Mime
View raw message