cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Mapping plugin ID -> URL
Date Wed, 02 Oct 2013 19:09:41 GMT
On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <anis.kadri@gmail.com> 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.


>
> 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?
> >> >
> >> >
> >> > On Wed, Oct 2, 2013 at 10:12 AM, Brian LeRoux <b@brian.io> wrote:
> >> >
> >> > > Ok, wanted clarity there. Node tried similar approaches and
> ultimately
> >> > they
> >> > > lead to complexity pain, and module author suffering.
> >> > >
> >> > > The recommended way (now) is npm or bundle/vendor dependencies. I
> think
> >> > > this is sane and easier. Could be convinced of the 'id' field
> allowing
> >> > for
> >> > > a Git url though.
> >> > >
> >> > >
> >> > > On Wed, Oct 2, 2013 at 1:41 AM, Andrew Grieve <agrieve@chromium.org
> >
> >> > > wrote:
> >> > >
> >> > > > E.g. for mobile-spec's dependency-plugin, it has <dependency
> >> > > > id="org.apache.cordova.file"> Instead of having plugman download
> it
> >> > from
> >> > > > the registry, I'd like to tell it to look for it locally.
> >> > > >
> >> > > > Not entirely sure what you mean by project level deps (do those
> >> exist)?
> >> > > >
> >> > > >
> >> > > > On Wed, Oct 2, 2013 at 12:45 AM, Brian LeRoux <b@brian.io>
wrote:
> >> > > >
> >> > > > > So wait, the use case is proj level deps not plugin level?
> >> > > > > On Oct 1, 2013 10:50 PM, "Andrew Grieve" <agrieve@chromium.org>
> >> > wrote:
> >> > > > >
> >> > > > > > There is a need to have plugman look in places other
than the
> >> > > registry
> >> > > > > when
> >> > > > > > fetching plugins by ID. This is particularly the case
because
> >> > > > > <dependency>
> >> > > > > > plugins now have IDs only instead of specifying a URL.
> >> > > > > >
> >> > > > > > Downstream distributions need this (e.g. IBM packages
plugins
> >> with
> >> > > > their
> >> > > > > > distro). But this would be nice for mobile-spec as
well
> >> (dependency
> >> > > > > plugin
> >> > > > > > could just list IDs instead of plugin paths).
> >> > > > > >
> >> > > > > > Idea #1:
> >> > > > > > Add a map to a project's .cordova/config.json with
explicit
> ID ->
> >> > URL
> >> > > > > > mappings. E.g.:
> >> > > > > > "plugin_map": {
> >> > > > > >   "org.apache.cordova.file": "file:///some/path",
> >> > > > > >   "org.apache.cordova.file-transfer": "
> http://git.com/url#hash"
> >> > > > > > }
> >> > > > > >
> >> > > > > > Idea #2
> >> > > > > > Add the idea of "plugin search path"
> >> > > > > > e.g.:
> >> > > > > > .cordova/config.json
> >> > > > > >    "plugin_search_path": ["file:///my/local/plugins",
"
> >> > > > > > http://my/custom/couch/db", "<inherits>"]
> >> > > > > >
> >> > > > > > Entries here can be:
> >> > > > > >   1. local directory where each subdirectory contains
a plugin
> >> > > > > >   2. http:// to a couchdb of a custom registry
> >> > > > > >   3. <inherits>, which means prepend this list
instead of
> >> replacing
> >> > > the
> >> > > > > > setting.
> >> > > > > >
> >> > > > > >
> >> > > > > > Idea #3
> >> > > > > > Allow the user to copy / symlink the plugin sources
into a
> >> projects
> >> > > > > > plugins/ directory. The directory names in here would
need to
> be
> >> > the
> >> > > > > plugin
> >> > > > > > IDs. When a request to install a plugin is made, plugman
will
> >> first
> >> > > > check
> >> > > > > > if it already exists within plugins/, and if so, uses
that
> >> source.
> >> > It
> >> > > > > would
> >> > > > > > also need to know not to delete the directory on plugin
rm.
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > #1 is nice because it's simple, but may not be super
> convenient
> >> > > (since
> >> > > > > you
> >> > > > > > need to explicitly add each plugin). It's also the
only
> >> suggestion
> >> > > that
> >> > > > > > allows you to map an ID to a custom git URL
> >> > > > > > #2 will work well for plugin collections, but may be
annoying
> if
> >> > you
> >> > > > just
> >> > > > > > want to override a single plugin location.
> >> > > > > > #3 is arguably the most flexible since it leaves the
fetching
> >> > > > completely
> >> > > > > up
> >> > > > > > to the user. It may encourage people to muck with their
> plugins/
> >> to
> >> > > the
> >> > > > > > point of breaking their project though. (e.g. they
may delete
> >> > plugins
> >> > > > > that
> >> > > > > > are installed)
> >> > > > > >
> >> > > > > >
> >> > > > > > I think I'd lean towards allowing both #1 and #2.
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

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