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 <agri...@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" <agri...@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.
> > >
> >
>
