Mapping plugin ID -> URL

[Andrew Grieve <ag...@chromium.org>]

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.

Re: Mapping plugin ID -> URL

[Michal Mocny <mm...@chromium.org>]

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

Re: Mapping plugin ID -> URL

[Andrew Grieve <ag...@chromium.org>]

https://issues.apache.org/jira/browse/CB-5006


On Thu, Oct 3, 2013 at 4:57 PM, Anis KADRI <an...@gmail.com> wrote:

> @Michal SGTM. The original approach has some other benefits on top of
> the current requirements. However, I don't know if we need those
> benefits just yet.
>
> On Thu, Oct 3, 2013 at 6:06 PM, Carlos Santana <cs...@gmail.com>
> wrote:
> > I think plugman is trying to do more than it should.
> > We should look into something like bower to handle dependencies and
> > fetching them to a local folder for a project.
> > Bower can be use by user via cli and plugman can use it as a node
> library.
> >
> > Bower handles the download of packages/repo with it's versions/tags to a
> > local folder.
> > I see a cordova plugin be analogous and not that different from a
> package.
> >
> > Then plugman uses a local folder (bower_components, cordova_components,
> > or what ever name) to install plugins from that folder.
> >
> > Cache only solved the problem of network usage, it doesn't solve
> > portability of a project/repo.
> >
> > I'm out on vacation but wanted to bring up Bower for front-end
> > dependencies. We can leverage their lessons learned or their code and we
> > don't have to re-invent the wheel.
> >
> > TLDR: I vote for plugman to have an option for install command to skip
> the
> > registry and use local folder already populated with a set of plugins.
> >
> > -- Carlos
> >
> >
> > On Thursday, October 3, 2013, Michal Mocny wrote:
> >
> >> On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny <mmocny@chromium.org
> <javascript:;>>
> >> wrote:
> >>
> >> >
> >> >
> >> >
> >> > On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <anis.kadri@gmail.com
> <javascript:;>>
> >> wrote:
> >> >
> >> >> Braden and I have talked about it in the past but there is already a
> >> >> $HOME/.plugman/cache and plugman will not attempt to fetch plugins if
> >> >> they are already in the cache. Unless I am missing something can you
> >> >> just not drop your dependencies in there?
> >> >>
> >> >
> >> > This sounds like it would work, but I'm hesitant to force a global
> >> > installation of the cache.  I think it would mean you cannot develop
> BB
> >> > webworks apps on the same machine as you develop vanilla cordova apps
> >> since
> >> > the same plugin id would map to different places across *all* plugman
> >> using
> >> > projects.
> >> >
> >> > Note that it already has been a source of problems to have things
> >> > needlessly added to ~/.cordova and ~/.plugman.
> >> >
> >>
> >> Thinking about this more, I think using the global cache is subtly
> >> different than what we want here.  However, I think we could perhaps
> >> leverage the concept and share most of the code.  Here is the big
> >> difference:
> >>
> >> - The global plugman cache is used *after* going out to registry to
> lookup
> >> latest version, so as not to download the same plugin version multiple
> >> times.
> >> - This proposed local search path is to be used *before* going out to
> >> registry, without caring about its content or version number.
> >>
> >> Perhaps the current behaviour can be decomposed into two steps: (1)
> "update
> >> global cache with newest plugin version via registry" and (2) "install
> >> plugin from cache".  Then, installing a plugin by ID could be:
> >>
> >> - Attempt Step (2) from local search path(s)
> >> - then, if above failed, do Step (1)
> >> - then, if above succeeded, Attempt Step (2) from global cache
> >>
> >> How does that sound?
> >>
> >>
> >> >
> >> >>
> >> >> Are there other use cases than simply 'not fetching from registry and
> >> >> using local path' for a given plugin ID ?
> >> >>
> >> >
> >> > I think this is the only use case we are looking to solve, but it
> shows
> >> up
> >> > in different situations: during cordova plugin add ID or plugman
> >> --install
> >> > with <dependancy> etc.
> >> >
> >> >
> >> >>
> >> >> #1 and #2 can be solutions to some problems but do we have those
> >> >> problems yet ? They can be a solution to managing multiple registry
> >> >> sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...)
> >> >> because right now we only support.
> >> >>
> >> >
> >> > Yes, we already do have these problems, as said: IBM, BB, and to some
> >> > extent Mobile-Chrome-Apps is already needing this solution.
> >>  Implementing a
> >> > new registry would be fine, if it worked offline for local-only
> installs,
> >> > preferably without the need to set up a server/couchdb for such simple
> >> > local only mappings, which is exactly Andrews proposal.
> >> >
> >> >
> >> >>
> >> >> Your proposed changes also seem to only affect CLI since you
> mentioned
> >> >> a ".cordova/config.json". plugman only users would potentially be
> >> >> penalized once again.
> >> >>
> >> >
> >> > I completely agree this is implemented in plugman.  We are discussing
> CLI
> >> > just to establish the convention for how to store the cache, but
> plugman
> >> > would have all the underlying functionality.  It *has* to be this way,
> >> > since its the one that resolves dependencies, and will need a new
> >> argument
> >> > alongside --install to know where to lookup id for local mapping.
> >> >
> >> >
> >> >>
> >> >> On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny <mm...@chromium.org>
> >> wrote:
> >> >> > I think the missing piece is that the plugin author has the option
> of
> >> >> > specifying dependencies in terms exactly *one* of these options:
> >> >> >
> >> >> > (a) id, to be looked up in the registry
> >> >> > (b) explicit git url
> >> >> > (c) relative path
> >> >> >
> >> >> > The problem is that a downstream *distributor* cannot override
> these
> >> >> values
> >> >> > at the moment, without making direct edits to the plugin.xml.  e.g.
> >> IBM
> >> >> and
> >> >> > BlackBerry have already both spoken up about the problem of
> shipping a
> >> >> > cordova based tool with plugins bundled, and having full control
> over
> >> >> > plugin versions, supporting offline work, etc.
> >> >> >
> >> >> > How can we solve the generic case of using the CLI with the
> registry,
> >> >> while
> >> >> > supporting the bundling/tarball use case?
> >> >> >
> >> >> > Andrews proposal would allow for option (a) to be overwritten by a
> >> >> > distributor without changes to the plugin.xml, by implementing a
> local
> >> >> > workspace mapping of id -> path, which is used by cli instead of
> >> >> reaching
> >> >> > out to the registry (though it could still use the registry for
> id's
> >> >> that
> >> >> > are not in the mapping).
> >> >> >
> >> >> > I suspect it would also make (a) the only necessary way to specify
> >> >> plugin
> >> >> > dependencies in practice, which I think is a win for simplicity.
> >>  Thats
> >> >> my
> >> >> > understanding anyway.
> >> >> >
> >> >> > -Michal
> >> >> >
> >> >> >
> >> >> > On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b...@brian.io> wrote:
> >> >> >
> >> >> >> Well, not npm but rather http://plugins.cordova.io or by URL or
> by
> >> >> >> relative
> >> >> >> path (allowing for vendored plugins). That is how Node does it TMK
> >> and
> >> >> >> should cover our use cases too without adding new config file
> options
> >> >> (or
> >> >> >> worse more config files).
> >> >> >>
> >> >> >> Am I missing something?
> >> >> >>
> >> >> >>
> >> >> >> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <
> agrieve@chromium.org>
> >> >> >> wrote:
> >> >> >>
> >> >> >> > Could you give an example of how you'd use npm or vendor
> >> >> dependencies?
> >> >> >> >
> >> >> >> >
> >> >> >>
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
>

Re: Mapping plugin ID -> URL

[Anis KADRI <an...@gmail.com>]

@Michal SGTM. The original approach has some other benefits on top of
the current requirements. However, I don't know if we need those
benefits just yet.

On Thu, Oct 3, 2013 at 6:06 PM, Carlos Santana <cs...@gmail.com> wrote:
> I think plugman is trying to do more than it should.
> We should look into something like bower to handle dependencies and
> fetching them to a local folder for a project.
> Bower can be use by user via cli and plugman can use it as a node library.
>
> Bower handles the download of packages/repo with it's versions/tags to a
> local folder.
> I see a cordova plugin be analogous and not that different from a package.
>
> Then plugman uses a local folder (bower_components, cordova_components,
> or what ever name) to install plugins from that folder.
>
> Cache only solved the problem of network usage, it doesn't solve
> portability of a project/repo.
>
> I'm out on vacation but wanted to bring up Bower for front-end
> dependencies. We can leverage their lessons learned or their code and we
> don't have to re-invent the wheel.
>
> TLDR: I vote for plugman to have an option for install command to skip the
> registry and use local folder already populated with a set of plugins.
>
> -- Carlos
>
>
> On Thursday, October 3, 2013, Michal Mocny wrote:
>
>> On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny <mmocny@chromium.org<javascript:;>>
>> wrote:
>>
>> >
>> >
>> >
>> > On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <anis.kadri@gmail.com<javascript:;>>
>> wrote:
>> >
>> >> Braden and I have talked about it in the past but there is already a
>> >> $HOME/.plugman/cache and plugman will not attempt to fetch plugins if
>> >> they are already in the cache. Unless I am missing something can you
>> >> just not drop your dependencies in there?
>> >>
>> >
>> > This sounds like it would work, but I'm hesitant to force a global
>> > installation of the cache.  I think it would mean you cannot develop BB
>> > webworks apps on the same machine as you develop vanilla cordova apps
>> since
>> > the same plugin id would map to different places across *all* plugman
>> using
>> > projects.
>> >
>> > Note that it already has been a source of problems to have things
>> > needlessly added to ~/.cordova and ~/.plugman.
>> >
>>
>> Thinking about this more, I think using the global cache is subtly
>> different than what we want here.  However, I think we could perhaps
>> leverage the concept and share most of the code.  Here is the big
>> difference:
>>
>> - The global plugman cache is used *after* going out to registry to lookup
>> latest version, so as not to download the same plugin version multiple
>> times.
>> - This proposed local search path is to be used *before* going out to
>> registry, without caring about its content or version number.
>>
>> Perhaps the current behaviour can be decomposed into two steps: (1) "update
>> global cache with newest plugin version via registry" and (2) "install
>> plugin from cache".  Then, installing a plugin by ID could be:
>>
>> - Attempt Step (2) from local search path(s)
>> - then, if above failed, do Step (1)
>> - then, if above succeeded, Attempt Step (2) from global cache
>>
>> How does that sound?
>>
>>
>> >
>> >>
>> >> Are there other use cases than simply 'not fetching from registry and
>> >> using local path' for a given plugin ID ?
>> >>
>> >
>> > I think this is the only use case we are looking to solve, but it shows
>> up
>> > in different situations: during cordova plugin add ID or plugman
>> --install
>> > with <dependancy> etc.
>> >
>> >
>> >>
>> >> #1 and #2 can be solutions to some problems but do we have those
>> >> problems yet ? They can be a solution to managing multiple registry
>> >> sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...)
>> >> because right now we only support.
>> >>
>> >
>> > Yes, we already do have these problems, as said: IBM, BB, and to some
>> > extent Mobile-Chrome-Apps is already needing this solution.
>>  Implementing a
>> > new registry would be fine, if it worked offline for local-only installs,
>> > preferably without the need to set up a server/couchdb for such simple
>> > local only mappings, which is exactly Andrews proposal.
>> >
>> >
>> >>
>> >> Your proposed changes also seem to only affect CLI since you mentioned
>> >> a ".cordova/config.json". plugman only users would potentially be
>> >> penalized once again.
>> >>
>> >
>> > I completely agree this is implemented in plugman.  We are discussing CLI
>> > just to establish the convention for how to store the cache, but plugman
>> > would have all the underlying functionality.  It *has* to be this way,
>> > since its the one that resolves dependencies, and will need a new
>> argument
>> > alongside --install to know where to lookup id for local mapping.
>> >
>> >
>> >>
>> >> On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny <mm...@chromium.org>
>> wrote:
>> >> > I think the missing piece is that the plugin author has the option of
>> >> > specifying dependencies in terms exactly *one* of these options:
>> >> >
>> >> > (a) id, to be looked up in the registry
>> >> > (b) explicit git url
>> >> > (c) relative path
>> >> >
>> >> > The problem is that a downstream *distributor* cannot override these
>> >> values
>> >> > at the moment, without making direct edits to the plugin.xml.  e.g.
>> IBM
>> >> and
>> >> > BlackBerry have already both spoken up about the problem of shipping a
>> >> > cordova based tool with plugins bundled, and having full control over
>> >> > plugin versions, supporting offline work, etc.
>> >> >
>> >> > How can we solve the generic case of using the CLI with the registry,
>> >> while
>> >> > supporting the bundling/tarball use case?
>> >> >
>> >> > Andrews proposal would allow for option (a) to be overwritten by a
>> >> > distributor without changes to the plugin.xml, by implementing a local
>> >> > workspace mapping of id -> path, which is used by cli instead of
>> >> reaching
>> >> > out to the registry (though it could still use the registry for id's
>> >> that
>> >> > are not in the mapping).
>> >> >
>> >> > I suspect it would also make (a) the only necessary way to specify
>> >> plugin
>> >> > dependencies in practice, which I think is a win for simplicity.
>>  Thats
>> >> my
>> >> > understanding anyway.
>> >> >
>> >> > -Michal
>> >> >
>> >> >
>> >> > On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b...@brian.io> wrote:
>> >> >
>> >> >> Well, not npm but rather http://plugins.cordova.io or by URL or by
>> >> >> relative
>> >> >> path (allowing for vendored plugins). That is how Node does it TMK
>> and
>> >> >> should cover our use cases too without adding new config file options
>> >> (or
>> >> >> worse more config files).
>> >> >>
>> >> >> Am I missing something?
>> >> >>
>> >> >>
>> >> >> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <ag...@chromium.org>
>> >> >> wrote:
>> >> >>
>> >> >> > Could you give an example of how you'd use npm or vendor
>> >> dependencies?
>> >> >> >
>> >> >> >
>> >> >>
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>

Re: Mapping plugin ID -> URL

[Carlos Santana <cs...@gmail.com>]

I think plugman is trying to do more than it should.
We should look into something like bower to handle dependencies and
fetching them to a local folder for a project.
Bower can be use by user via cli and plugman can use it as a node library.

Bower handles the download of packages/repo with it's versions/tags to a
local folder.
I see a cordova plugin be analogous and not that different from a package.

Then plugman uses a local folder (bower_components, cordova_components,
or what ever name) to install plugins from that folder.

Cache only solved the problem of network usage, it doesn't solve
portability of a project/repo.

I'm out on vacation but wanted to bring up Bower for front-end
dependencies. We can leverage their lessons learned or their code and we
don't have to re-invent the wheel.

TLDR: I vote for plugman to have an option for install command to skip the
registry and use local folder already populated with a set of plugins.

-- Carlos


On Thursday, October 3, 2013, Michal Mocny wrote:

> On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny <mmocny@chromium.org<javascript:;>>
> wrote:
>
> >
> >
> >
> > On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <anis.kadri@gmail.com<javascript:;>>
> wrote:
> >
> >> Braden and I have talked about it in the past but there is already a
> >> $HOME/.plugman/cache and plugman will not attempt to fetch plugins if
> >> they are already in the cache. Unless I am missing something can you
> >> just not drop your dependencies in there?
> >>
> >
> > This sounds like it would work, but I'm hesitant to force a global
> > installation of the cache.  I think it would mean you cannot develop BB
> > webworks apps on the same machine as you develop vanilla cordova apps
> since
> > the same plugin id would map to different places across *all* plugman
> using
> > projects.
> >
> > Note that it already has been a source of problems to have things
> > needlessly added to ~/.cordova and ~/.plugman.
> >
>
> Thinking about this more, I think using the global cache is subtly
> different than what we want here.  However, I think we could perhaps
> leverage the concept and share most of the code.  Here is the big
> difference:
>
> - The global plugman cache is used *after* going out to registry to lookup
> latest version, so as not to download the same plugin version multiple
> times.
> - This proposed local search path is to be used *before* going out to
> registry, without caring about its content or version number.
>
> Perhaps the current behaviour can be decomposed into two steps: (1) "update
> global cache with newest plugin version via registry" and (2) "install
> plugin from cache".  Then, installing a plugin by ID could be:
>
> - Attempt Step (2) from local search path(s)
> - then, if above failed, do Step (1)
> - then, if above succeeded, Attempt Step (2) from global cache
>
> How does that sound?
>
>
> >
> >>
> >> Are there other use cases than simply 'not fetching from registry and
> >> using local path' for a given plugin ID ?
> >>
> >
> > I think this is the only use case we are looking to solve, but it shows
> up
> > in different situations: during cordova plugin add ID or plugman
> --install
> > with <dependancy> etc.
> >
> >
> >>
> >> #1 and #2 can be solutions to some problems but do we have those
> >> problems yet ? They can be a solution to managing multiple registry
> >> sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...)
> >> because right now we only support.
> >>
> >
> > Yes, we already do have these problems, as said: IBM, BB, and to some
> > extent Mobile-Chrome-Apps is already needing this solution.
>  Implementing a
> > new registry would be fine, if it worked offline for local-only installs,
> > preferably without the need to set up a server/couchdb for such simple
> > local only mappings, which is exactly Andrews proposal.
> >
> >
> >>
> >> Your proposed changes also seem to only affect CLI since you mentioned
> >> a ".cordova/config.json". plugman only users would potentially be
> >> penalized once again.
> >>
> >
> > I completely agree this is implemented in plugman.  We are discussing CLI
> > just to establish the convention for how to store the cache, but plugman
> > would have all the underlying functionality.  It *has* to be this way,
> > since its the one that resolves dependencies, and will need a new
> argument
> > alongside --install to know where to lookup id for local mapping.
> >
> >
> >>
> >> On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >> > I think the missing piece is that the plugin author has the option of
> >> > specifying dependencies in terms exactly *one* of these options:
> >> >
> >> > (a) id, to be looked up in the registry
> >> > (b) explicit git url
> >> > (c) relative path
> >> >
> >> > The problem is that a downstream *distributor* cannot override these
> >> values
> >> > at the moment, without making direct edits to the plugin.xml.  e.g.
> IBM
> >> and
> >> > BlackBerry have already both spoken up about the problem of shipping a
> >> > cordova based tool with plugins bundled, and having full control over
> >> > plugin versions, supporting offline work, etc.
> >> >
> >> > How can we solve the generic case of using the CLI with the registry,
> >> while
> >> > supporting the bundling/tarball use case?
> >> >
> >> > Andrews proposal would allow for option (a) to be overwritten by a
> >> > distributor without changes to the plugin.xml, by implementing a local
> >> > workspace mapping of id -> path, which is used by cli instead of
> >> reaching
> >> > out to the registry (though it could still use the registry for id's
> >> that
> >> > are not in the mapping).
> >> >
> >> > I suspect it would also make (a) the only necessary way to specify
> >> plugin
> >> > dependencies in practice, which I think is a win for simplicity.
>  Thats
> >> my
> >> > understanding anyway.
> >> >
> >> > -Michal
> >> >
> >> >
> >> > On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b...@brian.io> wrote:
> >> >
> >> >> Well, not npm but rather http://plugins.cordova.io or by URL or by
> >> >> relative
> >> >> path (allowing for vendored plugins). That is how Node does it TMK
> and
> >> >> should cover our use cases too without adding new config file options
> >> (or
> >> >> worse more config files).
> >> >>
> >> >> Am I missing something?
> >> >>
> >> >>
> >> >> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <ag...@chromium.org>
> >> >> wrote:
> >> >>
> >> >> > Could you give an example of how you'd use npm or vendor
> >> dependencies?
> >> >> >
> >> >> >
> >> >>



-- 
Carlos Santana
<cs...@gmail.com>

Re: Mapping plugin ID -> URL

[Michal Mocny <mm...@chromium.org>]

On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny <mm...@chromium.org> wrote:

>
>
>
> On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <an...@gmail.com> wrote:
>
>> Braden and I have talked about it in the past but there is already a
>> $HOME/.plugman/cache and plugman will not attempt to fetch plugins if
>> they are already in the cache. Unless I am missing something can you
>> just not drop your dependencies in there?
>>
>
> This sounds like it would work, but I'm hesitant to force a global
> installation of the cache.  I think it would mean you cannot develop BB
> webworks apps on the same machine as you develop vanilla cordova apps since
> the same plugin id would map to different places across *all* plugman using
> projects.
>
> Note that it already has been a source of problems to have things
> needlessly added to ~/.cordova and ~/.plugman.
>

Thinking about this more, I think using the global cache is subtly
different than what we want here.  However, I think we could perhaps
leverage the concept and share most of the code.  Here is the big
difference:

- The global plugman cache is used *after* going out to registry to lookup
latest version, so as not to download the same plugin version multiple
times.
- This proposed local search path is to be used *before* going out to
registry, without caring about its content or version number.

Perhaps the current behaviour can be decomposed into two steps: (1) "update
global cache with newest plugin version via registry" and (2) "install
plugin from cache".  Then, installing a plugin by ID could be:

- Attempt Step (2) from local search path(s)
- then, if above failed, do Step (1)
- then, if above succeeded, Attempt Step (2) from global cache

How does that sound?


>
>>
>> Are there other use cases than simply 'not fetching from registry and
>> using local path' for a given plugin ID ?
>>
>
> I think this is the only use case we are looking to solve, but it shows up
> in different situations: during cordova plugin add ID or plugman --install
> with <dependancy> etc.
>
>
>>
>> #1 and #2 can be solutions to some problems but do we have those
>> problems yet ? They can be a solution to managing multiple registry
>> sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...)
>> because right now we only support.
>>
>
> Yes, we already do have these problems, as said: IBM, BB, and to some
> extent Mobile-Chrome-Apps is already needing this solution.  Implementing a
> new registry would be fine, if it worked offline for local-only installs,
> preferably without the need to set up a server/couchdb for such simple
> local only mappings, which is exactly Andrews proposal.
>
>
>>
>> Your proposed changes also seem to only affect CLI since you mentioned
>> a ".cordova/config.json". plugman only users would potentially be
>> penalized once again.
>>
>
> I completely agree this is implemented in plugman.  We are discussing CLI
> just to establish the convention for how to store the cache, but plugman
> would have all the underlying functionality.  It *has* to be this way,
> since its the one that resolves dependencies, and will need a new argument
> alongside --install to know where to lookup id for local mapping.
>
>
>>
>> On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny <mm...@chromium.org> wrote:
>> > I think the missing piece is that the plugin author has the option of
>> > specifying dependencies in terms exactly *one* of these options:
>> >
>> > (a) id, to be looked up in the registry
>> > (b) explicit git url
>> > (c) relative path
>> >
>> > The problem is that a downstream *distributor* cannot override these
>> values
>> > at the moment, without making direct edits to the plugin.xml.  e.g. IBM
>> and
>> > BlackBerry have already both spoken up about the problem of shipping a
>> > cordova based tool with plugins bundled, and having full control over
>> > plugin versions, supporting offline work, etc.
>> >
>> > How can we solve the generic case of using the CLI with the registry,
>> while
>> > supporting the bundling/tarball use case?
>> >
>> > Andrews proposal would allow for option (a) to be overwritten by a
>> > distributor without changes to the plugin.xml, by implementing a local
>> > workspace mapping of id -> path, which is used by cli instead of
>> reaching
>> > out to the registry (though it could still use the registry for id's
>> that
>> > are not in the mapping).
>> >
>> > I suspect it would also make (a) the only necessary way to specify
>> plugin
>> > dependencies in practice, which I think is a win for simplicity.  Thats
>> my
>> > understanding anyway.
>> >
>> > -Michal
>> >
>> >
>> > On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> >> Well, not npm but rather http://plugins.cordova.io or by URL or by
>> >> relative
>> >> path (allowing for vendored plugins). That is how Node does it TMK and
>> >> should cover our use cases too without adding new config file options
>> (or
>> >> worse more config files).
>> >>
>> >> Am I missing something?
>> >>
>> >>
>> >> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <ag...@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 <
>> 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.
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>
>

Re: Mapping plugin ID -> URL

[Michal Mocny <mm...@chromium.org>]

On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <an...@gmail.com> wrote:

> Braden and I have talked about it in the past but there is already a
> $HOME/.plugman/cache and plugman will not attempt to fetch plugins if
> they are already in the cache. Unless I am missing something can you
> just not drop your dependencies in there?
>

This sounds like it would work, but I'm hesitant to force a global
installation of the cache.  I think it would mean you cannot develop BB
webworks apps on the same machine as you develop vanilla cordova apps since
the same plugin id would map to different places across *all* plugman using
projects.

Note that it already has been a source of problems to have things
needlessly added to ~/.cordova and ~/.plugman.


>
> Are there other use cases than simply 'not fetching from registry and
> using local path' for a given plugin ID ?
>

I think this is the only use case we are looking to solve, but it shows up
in different situations: during cordova plugin add ID or plugman --install
with <dependancy> etc.


>
> #1 and #2 can be solutions to some problems but do we have those
> problems yet ? They can be a solution to managing multiple registry
> sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...)
> because right now we only support.
>

Yes, we already do have these problems, as said: IBM, BB, and to some
extent Mobile-Chrome-Apps is already needing this solution.  Implementing a
new registry would be fine, if it worked offline for local-only installs,
preferably without the need to set up a server/couchdb for such simple
local only mappings, which is exactly Andrews proposal.


>
> Your proposed changes also seem to only affect CLI since you mentioned
> a ".cordova/config.json". plugman only users would potentially be
> penalized once again.
>

I completely agree this is implemented in plugman.  We are discussing CLI
just to establish the convention for how to store the cache, but plugman
would have all the underlying functionality.  It *has* to be this way,
since its the one that resolves dependencies, and will need a new argument
alongside --install to know where to lookup id for local mapping.


>
> On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny <mm...@chromium.org> wrote:
> > I think the missing piece is that the plugin author has the option of
> > specifying dependencies in terms exactly *one* of these options:
> >
> > (a) id, to be looked up in the registry
> > (b) explicit git url
> > (c) relative path
> >
> > The problem is that a downstream *distributor* cannot override these
> values
> > at the moment, without making direct edits to the plugin.xml.  e.g. IBM
> and
> > BlackBerry have already both spoken up about the problem of shipping a
> > cordova based tool with plugins bundled, and having full control over
> > plugin versions, supporting offline work, etc.
> >
> > How can we solve the generic case of using the CLI with the registry,
> while
> > supporting the bundling/tarball use case?
> >
> > Andrews proposal would allow for option (a) to be overwritten by a
> > distributor without changes to the plugin.xml, by implementing a local
> > workspace mapping of id -> path, which is used by cli instead of reaching
> > out to the registry (though it could still use the registry for id's that
> > are not in the mapping).
> >
> > I suspect it would also make (a) the only necessary way to specify plugin
> > dependencies in practice, which I think is a win for simplicity.  Thats
> my
> > understanding anyway.
> >
> > -Michal
> >
> >
> > On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> Well, not npm but rather http://plugins.cordova.io or by URL or by
> >> relative
> >> path (allowing for vendored plugins). That is how Node does it TMK and
> >> should cover our use cases too without adding new config file options
> (or
> >> worse more config files).
> >>
> >> Am I missing something?
> >>
> >>
> >> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <ag...@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 <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" <ag...@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.
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

Re: Mapping plugin ID -> URL

[Anis KADRI <an...@gmail.com>]

Braden and I have talked about it in the past but there is already a
$HOME/.plugman/cache and plugman will not attempt to fetch plugins if
they are already in the cache. Unless I am missing something can you
just not drop your dependencies in there?

Are there other use cases than simply 'not fetching from registry and
using local path' for a given plugin ID ?

#1 and #2 can be solutions to some problems but do we have those
problems yet ? They can be a solution to managing multiple registry
sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...)
because right now we only support.

Your proposed changes also seem to only affect CLI since you mentioned
a ".cordova/config.json". plugman only users would potentially be
penalized once again.

On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny <mm...@chromium.org> wrote:
> I think the missing piece is that the plugin author has the option of
> specifying dependencies in terms exactly *one* of these options:
>
> (a) id, to be looked up in the registry
> (b) explicit git url
> (c) relative path
>
> The problem is that a downstream *distributor* cannot override these values
> at the moment, without making direct edits to the plugin.xml.  e.g. IBM and
> BlackBerry have already both spoken up about the problem of shipping a
> cordova based tool with plugins bundled, and having full control over
> plugin versions, supporting offline work, etc.
>
> How can we solve the generic case of using the CLI with the registry, while
> supporting the bundling/tarball use case?
>
> Andrews proposal would allow for option (a) to be overwritten by a
> distributor without changes to the plugin.xml, by implementing a local
> workspace mapping of id -> path, which is used by cli instead of reaching
> out to the registry (though it could still use the registry for id's that
> are not in the mapping).
>
> I suspect it would also make (a) the only necessary way to specify plugin
> dependencies in practice, which I think is a win for simplicity.  Thats my
> understanding anyway.
>
> -Michal
>
>
> On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> Well, not npm but rather http://plugins.cordova.io or by URL or by
>> relative
>> path (allowing for vendored plugins). That is how Node does it TMK and
>> should cover our use cases too without adding new config file options (or
>> worse more config files).
>>
>> Am I missing something?
>>
>>
>> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <ag...@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 <ag...@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" <ag...@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.
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>

Re: Mapping plugin ID -> URL

[Michal Mocny <mm...@chromium.org>]

I think the missing piece is that the plugin author has the option of
specifying dependencies in terms exactly *one* of these options:

(a) id, to be looked up in the registry
(b) explicit git url
(c) relative path

The problem is that a downstream *distributor* cannot override these values
at the moment, without making direct edits to the plugin.xml.  e.g. IBM and
BlackBerry have already both spoken up about the problem of shipping a
cordova based tool with plugins bundled, and having full control over
plugin versions, supporting offline work, etc.

How can we solve the generic case of using the CLI with the registry, while
supporting the bundling/tarball use case?

Andrews proposal would allow for option (a) to be overwritten by a
distributor without changes to the plugin.xml, by implementing a local
workspace mapping of id -> path, which is used by cli instead of reaching
out to the registry (though it could still use the registry for id's that
are not in the mapping).

I suspect it would also make (a) the only necessary way to specify plugin
dependencies in practice, which I think is a win for simplicity.  Thats my
understanding anyway.

-Michal


On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b...@brian.io> wrote:

> Well, not npm but rather http://plugins.cordova.io or by URL or by
> relative
> path (allowing for vendored plugins). That is how Node does it TMK and
> should cover our use cases too without adding new config file options (or
> worse more config files).
>
> Am I missing something?
>
>
> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <ag...@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 <ag...@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" <ag...@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.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Mapping plugin ID -> URL

[Brian LeRoux <b...@brian.io>]

Well, not npm but rather http://plugins.cordova.io or by URL or by relative
path (allowing for vendored plugins). That is how Node does it TMK and
should cover our use cases too without adding new config file options (or
worse more config files).

Am I missing something?


On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <ag...@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 <ag...@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" <ag...@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.
> > > > >
> > > >
> > >
> >
>

Re: Mapping plugin ID -> URL

[Andrew Grieve <ag...@chromium.org>]

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

Re: Mapping plugin ID -> URL

[Brian LeRoux <b...@brian.io>]

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

Re: Mapping plugin ID -> URL

[Andrew Grieve <ag...@chromium.org>]

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

Re: Mapping plugin ID -> URL

[Brian LeRoux <b...@brian.io>]

So wait, the use case is proj level deps not plugin level?
On Oct 1, 2013 10:50 PM, "Andrew Grieve" <ag...@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.
>