cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Mapping plugin ID -> URL
Date Wed, 02 Oct 2013 09:12:56 GMT
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