cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Mapping plugin ID -> URL
Date Mon, 07 Oct 2013 17:34:30 GMT
https://issues.apache.org/jira/browse/CB-5006


On Thu, Oct 3, 2013 at 4:57 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> @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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message