cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: Mapping plugin ID -> URL
Date Thu, 03 Oct 2013 16:06:13 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message