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