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.
>
