I like the simplicity and intuitiveness of #3 but think its problematic to
use the plugins/ folder directly, since right now those are *installed*
plugins, not just "available for install".
We had a similar problem with the "plugin create" proposal, wherein we were
not sure how to handle removing the plugin (say, temporarily to reinstall
it) and we did not want to actually delete the source code (since that may
be the only version/be your git repo), but did want to remove its entry
from plugins/. Best solution we had was for create to --link from plugins/
to some more persistent local folder.
I think this encourages a single generalized solution:
Why not stick with a directory based approach, but create a new location
specifically for this purpose? Perhaps .cordova/plugins/ or
plugins/SOURCES/? Or separate plugins/ into a plugins/installed/ and
plugins/cache/ and have installed --link into cache?
-Michal
On Wed, Oct 2, 2013 at 9:31 AM, Andrew Grieve <agri...@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 <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.
> > > > >
> > > >
> > >
> >
>
