Registry based plugins and tags

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

The logic is:
- If there's a url, use it, otherwise use the registry.

If I'm developing on a plugin, and that plugin has a dependency, I don't
want it fetching it from the registry. I could change the <dependency> to
have a url= to the local path, but then I need to remember to take that out
before publishing.

So... I'm thinking it would be useful to allow projects to provide their
own file-backed local registry. E.g. a JSON file of pluginId -> url/path.
Where the new algorithm would be:

if id in localRegistry, use that url, otherwise, use the registry.

I think this will be super useful for projects that want to distribute
plugins off-registry as well.

Question is - where's the best place for this?

My first thought was in CLI's .cordova/config.json, but that won't work for
plugman projects. homedir may address some use-cases, but project-specific
local registry is still important I think. So... Maybe for CLI projects, we
put it in .cordova/config.json and for plugman you use a
--localregistry=FILE flag?

Re: Registry based plugins and tags

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

It doesn't, but maybe it could?..  If plugman prepare would actually
properly "install" a plugin then we could probably link to global managed
versions.  Not sure how feasible that is.


On Sun, Sep 22, 2013 at 11:31 AM, Andrew Grieve <ag...@chromium.org>wrote:

> One thing about link, is that it makes a lot of sense when you have the
> notion of global vs local modules. E.g. it can make global modules depend
> on local ones, and local ones depend on global ones. By double-linking, you
> can make local ones depend on other local ones through the global one.
> Cordova doesn't have the notion of globally-installed plugins, so the
> concept doesn't really map well.
>
>
> On Sun, Sep 22, 2013 at 11:04 AM, Michael Brooks
> <mi...@michaelbrooks.ca>wrote:
>
> > >
> > > Can you iterate the reasons? I've enjoyed link but maybe I'm lucky.
> >
> >
> > npm link has been great for me as well. I'd love to hear about the
> > pitfalls.
> >
> > The only one I've experienced is accidentally publishing a package and
> > forgetting to publish an updated dependency that I locally linked.
> However,
> > Travis-CI immediately catches the error thanks to the test suite.
> >
> >
> > On Sun, Sep 22, 2013 at 4:49 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > Can you iterate the reasons? I've enjoyed link but maybe I'm lucky.
> > > On Sep 20, 2013 1:33 PM, "Anis KADRI" <an...@gmail.com> wrote:
> > >
> > > > "link is messy". says one nodejs wise man. I want to stay as far away
> > > > from it as possible for so many different reasons.
> > > >
> > > > plugman doesn't fetch anything from registry if version is in the
> > > > cache. The version lands in the cache if you publish it yourself.
> It's
> > > > not cached when you fetch/install. Therefore if the plugin is not
> your
> > > > plugin, you need to make sure that the version is up to date because
> > > > the tool assumes it is since it's _your_ plugin. Do we still need a
> > > > local registry in this case ? The cache could be the local registry.
> > > >
> > > >
> > > >
> > > > On Fri, Sep 20, 2013 at 12:40 PM, Brian LeRoux <b...@brian.io> wrote:
> > > > > `npm help link`
> > > > >
> > > > >
> > > > > On Thu, Sep 19, 2013 at 9:03 PM, David Kemp <dr...@google.com>
> > wrote:
> > > > >
> > > > >> +1 for project specific registry (not home dir)
> > > > >>
> > > > >>
> > > > >> On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson <
> > > > braden@chromium.org
> > > > >> >wrote:
> > > > >>
> > > > >> > One alternative is to symlink it into $HOME/.plugman/cache/
> > > > my.plugin.id.
> > > > >> > Then plugman when fetching it will use that, assuming the
> version
> > is
> > > > new
> > > > >> > enough. I think the right place for the file is in
> > > > >> > ~/.plugman/localRegistry.json or similar, since fetching plugins
> > is
> > > > >> > definitely plugman's responsibility and not CLI's.
> > > > >> >
> > > > >> > Braden
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve <
> > > agrieve@chromium.org>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > The logic is:
> > > > >> > > - If there's a url, use it, otherwise use the registry.
> > > > >> > >
> > > > >> > > If I'm developing on a plugin, and that plugin has a
> > dependency, I
> > > > >> don't
> > > > >> > > want it fetching it from the registry. I could change the
> > > > <dependency>
> > > > >> to
> > > > >> > > have a url= to the local path, but then I need to remember to
> > take
> > > > that
> > > > >> > out
> > > > >> > > before publishing.
> > > > >> > >
> > > > >> > > So... I'm thinking it would be useful to allow projects to
> > provide
> > > > >> their
> > > > >> > > own file-backed local registry. E.g. a JSON file of pluginId
> ->
> > > > >> url/path.
> > > > >> > > Where the new algorithm would be:
> > > > >> > >
> > > > >> > > if id in localRegistry, use that url, otherwise, use the
> > registry.
> > > > >> > >
> > > > >> > > I think this will be super useful for projects that want to
> > > > distribute
> > > > >> > > plugins off-registry as well.
> > > > >> > >
> > > > >> > > Question is - where's the best place for this?
> > > > >> > >
> > > > >> > > My first thought was in CLI's .cordova/config.json, but that
> > won't
> > > > work
> > > > >> > for
> > > > >> > > plugman projects. homedir may address some use-cases, but
> > > > >> > project-specific
> > > > >> > > local registry is still important I think. So... Maybe for CLI
> > > > >> projects,
> > > > >> > we
> > > > >> > > put it in .cordova/config.json and for plugman you use a
> > > > >> > > --localregistry=FILE flag?
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>

Re: Registry based plugins and tags

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

One thing about link, is that it makes a lot of sense when you have the
notion of global vs local modules. E.g. it can make global modules depend
on local ones, and local ones depend on global ones. By double-linking, you
can make local ones depend on other local ones through the global one.
Cordova doesn't have the notion of globally-installed plugins, so the
concept doesn't really map well.


On Sun, Sep 22, 2013 at 11:04 AM, Michael Brooks
<mi...@michaelbrooks.ca>wrote:

> >
> > Can you iterate the reasons? I've enjoyed link but maybe I'm lucky.
>
>
> npm link has been great for me as well. I'd love to hear about the
> pitfalls.
>
> The only one I've experienced is accidentally publishing a package and
> forgetting to publish an updated dependency that I locally linked. However,
> Travis-CI immediately catches the error thanks to the test suite.
>
>
> On Sun, Sep 22, 2013 at 4:49 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > Can you iterate the reasons? I've enjoyed link but maybe I'm lucky.
> > On Sep 20, 2013 1:33 PM, "Anis KADRI" <an...@gmail.com> wrote:
> >
> > > "link is messy". says one nodejs wise man. I want to stay as far away
> > > from it as possible for so many different reasons.
> > >
> > > plugman doesn't fetch anything from registry if version is in the
> > > cache. The version lands in the cache if you publish it yourself. It's
> > > not cached when you fetch/install. Therefore if the plugin is not your
> > > plugin, you need to make sure that the version is up to date because
> > > the tool assumes it is since it's _your_ plugin. Do we still need a
> > > local registry in this case ? The cache could be the local registry.
> > >
> > >
> > >
> > > On Fri, Sep 20, 2013 at 12:40 PM, Brian LeRoux <b...@brian.io> wrote:
> > > > `npm help link`
> > > >
> > > >
> > > > On Thu, Sep 19, 2013 at 9:03 PM, David Kemp <dr...@google.com>
> wrote:
> > > >
> > > >> +1 for project specific registry (not home dir)
> > > >>
> > > >>
> > > >> On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson <
> > > braden@chromium.org
> > > >> >wrote:
> > > >>
> > > >> > One alternative is to symlink it into $HOME/.plugman/cache/
> > > my.plugin.id.
> > > >> > Then plugman when fetching it will use that, assuming the version
> is
> > > new
> > > >> > enough. I think the right place for the file is in
> > > >> > ~/.plugman/localRegistry.json or similar, since fetching plugins
> is
> > > >> > definitely plugman's responsibility and not CLI's.
> > > >> >
> > > >> > Braden
> > > >> >
> > > >> >
> > > >> > On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve <
> > agrieve@chromium.org>
> > > >> > wrote:
> > > >> >
> > > >> > > The logic is:
> > > >> > > - If there's a url, use it, otherwise use the registry.
> > > >> > >
> > > >> > > If I'm developing on a plugin, and that plugin has a
> dependency, I
> > > >> don't
> > > >> > > want it fetching it from the registry. I could change the
> > > <dependency>
> > > >> to
> > > >> > > have a url= to the local path, but then I need to remember to
> take
> > > that
> > > >> > out
> > > >> > > before publishing.
> > > >> > >
> > > >> > > So... I'm thinking it would be useful to allow projects to
> provide
> > > >> their
> > > >> > > own file-backed local registry. E.g. a JSON file of pluginId ->
> > > >> url/path.
> > > >> > > Where the new algorithm would be:
> > > >> > >
> > > >> > > if id in localRegistry, use that url, otherwise, use the
> registry.
> > > >> > >
> > > >> > > I think this will be super useful for projects that want to
> > > distribute
> > > >> > > plugins off-registry as well.
> > > >> > >
> > > >> > > Question is - where's the best place for this?
> > > >> > >
> > > >> > > My first thought was in CLI's .cordova/config.json, but that
> won't
> > > work
> > > >> > for
> > > >> > > plugman projects. homedir may address some use-cases, but
> > > >> > project-specific
> > > >> > > local registry is still important I think. So... Maybe for CLI
> > > >> projects,
> > > >> > we
> > > >> > > put it in .cordova/config.json and for plugman you use a
> > > >> > > --localregistry=FILE flag?
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

Re: Registry based plugins and tags

[Michael Brooks <mi...@michaelbrooks.ca>]

>
> Can you iterate the reasons? I've enjoyed link but maybe I'm lucky.


npm link has been great for me as well. I'd love to hear about the pitfalls.

The only one I've experienced is accidentally publishing a package and
forgetting to publish an updated dependency that I locally linked. However,
Travis-CI immediately catches the error thanks to the test suite.


On Sun, Sep 22, 2013 at 4:49 PM, Brian LeRoux <b...@brian.io> wrote:

> Can you iterate the reasons? I've enjoyed link but maybe I'm lucky.
> On Sep 20, 2013 1:33 PM, "Anis KADRI" <an...@gmail.com> wrote:
>
> > "link is messy". says one nodejs wise man. I want to stay as far away
> > from it as possible for so many different reasons.
> >
> > plugman doesn't fetch anything from registry if version is in the
> > cache. The version lands in the cache if you publish it yourself. It's
> > not cached when you fetch/install. Therefore if the plugin is not your
> > plugin, you need to make sure that the version is up to date because
> > the tool assumes it is since it's _your_ plugin. Do we still need a
> > local registry in this case ? The cache could be the local registry.
> >
> >
> >
> > On Fri, Sep 20, 2013 at 12:40 PM, Brian LeRoux <b...@brian.io> wrote:
> > > `npm help link`
> > >
> > >
> > > On Thu, Sep 19, 2013 at 9:03 PM, David Kemp <dr...@google.com> wrote:
> > >
> > >> +1 for project specific registry (not home dir)
> > >>
> > >>
> > >> On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson <
> > braden@chromium.org
> > >> >wrote:
> > >>
> > >> > One alternative is to symlink it into $HOME/.plugman/cache/
> > my.plugin.id.
> > >> > Then plugman when fetching it will use that, assuming the version is
> > new
> > >> > enough. I think the right place for the file is in
> > >> > ~/.plugman/localRegistry.json or similar, since fetching plugins is
> > >> > definitely plugman's responsibility and not CLI's.
> > >> >
> > >> > Braden
> > >> >
> > >> >
> > >> > On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve <
> agrieve@chromium.org>
> > >> > wrote:
> > >> >
> > >> > > The logic is:
> > >> > > - If there's a url, use it, otherwise use the registry.
> > >> > >
> > >> > > If I'm developing on a plugin, and that plugin has a dependency, I
> > >> don't
> > >> > > want it fetching it from the registry. I could change the
> > <dependency>
> > >> to
> > >> > > have a url= to the local path, but then I need to remember to take
> > that
> > >> > out
> > >> > > before publishing.
> > >> > >
> > >> > > So... I'm thinking it would be useful to allow projects to provide
> > >> their
> > >> > > own file-backed local registry. E.g. a JSON file of pluginId ->
> > >> url/path.
> > >> > > Where the new algorithm would be:
> > >> > >
> > >> > > if id in localRegistry, use that url, otherwise, use the registry.
> > >> > >
> > >> > > I think this will be super useful for projects that want to
> > distribute
> > >> > > plugins off-registry as well.
> > >> > >
> > >> > > Question is - where's the best place for this?
> > >> > >
> > >> > > My first thought was in CLI's .cordova/config.json, but that won't
> > work
> > >> > for
> > >> > > plugman projects. homedir may address some use-cases, but
> > >> > project-specific
> > >> > > local registry is still important I think. So... Maybe for CLI
> > >> projects,
> > >> > we
> > >> > > put it in .cordova/config.json and for plugman you use a
> > >> > > --localregistry=FILE flag?
> > >> > >
> > >> >
> > >>
> >
>

Re: Registry based plugins and tags

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

Can you iterate the reasons? I've enjoyed link but maybe I'm lucky.
On Sep 20, 2013 1:33 PM, "Anis KADRI" <an...@gmail.com> wrote:

> "link is messy". says one nodejs wise man. I want to stay as far away
> from it as possible for so many different reasons.
>
> plugman doesn't fetch anything from registry if version is in the
> cache. The version lands in the cache if you publish it yourself. It's
> not cached when you fetch/install. Therefore if the plugin is not your
> plugin, you need to make sure that the version is up to date because
> the tool assumes it is since it's _your_ plugin. Do we still need a
> local registry in this case ? The cache could be the local registry.
>
>
>
> On Fri, Sep 20, 2013 at 12:40 PM, Brian LeRoux <b...@brian.io> wrote:
> > `npm help link`
> >
> >
> > On Thu, Sep 19, 2013 at 9:03 PM, David Kemp <dr...@google.com> wrote:
> >
> >> +1 for project specific registry (not home dir)
> >>
> >>
> >> On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson <
> braden@chromium.org
> >> >wrote:
> >>
> >> > One alternative is to symlink it into $HOME/.plugman/cache/
> my.plugin.id.
> >> > Then plugman when fetching it will use that, assuming the version is
> new
> >> > enough. I think the right place for the file is in
> >> > ~/.plugman/localRegistry.json or similar, since fetching plugins is
> >> > definitely plugman's responsibility and not CLI's.
> >> >
> >> > Braden
> >> >
> >> >
> >> > On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve <ag...@chromium.org>
> >> > wrote:
> >> >
> >> > > The logic is:
> >> > > - If there's a url, use it, otherwise use the registry.
> >> > >
> >> > > If I'm developing on a plugin, and that plugin has a dependency, I
> >> don't
> >> > > want it fetching it from the registry. I could change the
> <dependency>
> >> to
> >> > > have a url= to the local path, but then I need to remember to take
> that
> >> > out
> >> > > before publishing.
> >> > >
> >> > > So... I'm thinking it would be useful to allow projects to provide
> >> their
> >> > > own file-backed local registry. E.g. a JSON file of pluginId ->
> >> url/path.
> >> > > Where the new algorithm would be:
> >> > >
> >> > > if id in localRegistry, use that url, otherwise, use the registry.
> >> > >
> >> > > I think this will be super useful for projects that want to
> distribute
> >> > > plugins off-registry as well.
> >> > >
> >> > > Question is - where's the best place for this?
> >> > >
> >> > > My first thought was in CLI's .cordova/config.json, but that won't
> work
> >> > for
> >> > > plugman projects. homedir may address some use-cases, but
> >> > project-specific
> >> > > local registry is still important I think. So... Maybe for CLI
> >> projects,
> >> > we
> >> > > put it in .cordova/config.json and for plugman you use a
> >> > > --localregistry=FILE flag?
> >> > >
> >> >
> >>
>

Re: Registry based plugins and tags

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

"link is messy". says one nodejs wise man. I want to stay as far away
from it as possible for so many different reasons.

plugman doesn't fetch anything from registry if version is in the
cache. The version lands in the cache if you publish it yourself. It's
not cached when you fetch/install. Therefore if the plugin is not your
plugin, you need to make sure that the version is up to date because
the tool assumes it is since it's _your_ plugin. Do we still need a
local registry in this case ? The cache could be the local registry.



On Fri, Sep 20, 2013 at 12:40 PM, Brian LeRoux <b...@brian.io> wrote:
> `npm help link`
>
>
> On Thu, Sep 19, 2013 at 9:03 PM, David Kemp <dr...@google.com> wrote:
>
>> +1 for project specific registry (not home dir)
>>
>>
>> On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson <braden@chromium.org
>> >wrote:
>>
>> > One alternative is to symlink it into $HOME/.plugman/cache/my.plugin.id.
>> > Then plugman when fetching it will use that, assuming the version is new
>> > enough. I think the right place for the file is in
>> > ~/.plugman/localRegistry.json or similar, since fetching plugins is
>> > definitely plugman's responsibility and not CLI's.
>> >
>> > Braden
>> >
>> >
>> > On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve <ag...@chromium.org>
>> > wrote:
>> >
>> > > The logic is:
>> > > - If there's a url, use it, otherwise use the registry.
>> > >
>> > > If I'm developing on a plugin, and that plugin has a dependency, I
>> don't
>> > > want it fetching it from the registry. I could change the <dependency>
>> to
>> > > have a url= to the local path, but then I need to remember to take that
>> > out
>> > > before publishing.
>> > >
>> > > So... I'm thinking it would be useful to allow projects to provide
>> their
>> > > own file-backed local registry. E.g. a JSON file of pluginId ->
>> url/path.
>> > > Where the new algorithm would be:
>> > >
>> > > if id in localRegistry, use that url, otherwise, use the registry.
>> > >
>> > > I think this will be super useful for projects that want to distribute
>> > > plugins off-registry as well.
>> > >
>> > > Question is - where's the best place for this?
>> > >
>> > > My first thought was in CLI's .cordova/config.json, but that won't work
>> > for
>> > > plugman projects. homedir may address some use-cases, but
>> > project-specific
>> > > local registry is still important I think. So... Maybe for CLI
>> projects,
>> > we
>> > > put it in .cordova/config.json and for plugman you use a
>> > > --localregistry=FILE flag?
>> > >
>> >
>>

Re: Registry based plugins and tags

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

`npm help link`


On Thu, Sep 19, 2013 at 9:03 PM, David Kemp <dr...@google.com> wrote:

> +1 for project specific registry (not home dir)
>
>
> On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > One alternative is to symlink it into $HOME/.plugman/cache/my.plugin.id.
> > Then plugman when fetching it will use that, assuming the version is new
> > enough. I think the right place for the file is in
> > ~/.plugman/localRegistry.json or similar, since fetching plugins is
> > definitely plugman's responsibility and not CLI's.
> >
> > Braden
> >
> >
> > On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > The logic is:
> > > - If there's a url, use it, otherwise use the registry.
> > >
> > > If I'm developing on a plugin, and that plugin has a dependency, I
> don't
> > > want it fetching it from the registry. I could change the <dependency>
> to
> > > have a url= to the local path, but then I need to remember to take that
> > out
> > > before publishing.
> > >
> > > So... I'm thinking it would be useful to allow projects to provide
> their
> > > own file-backed local registry. E.g. a JSON file of pluginId ->
> url/path.
> > > Where the new algorithm would be:
> > >
> > > if id in localRegistry, use that url, otherwise, use the registry.
> > >
> > > I think this will be super useful for projects that want to distribute
> > > plugins off-registry as well.
> > >
> > > Question is - where's the best place for this?
> > >
> > > My first thought was in CLI's .cordova/config.json, but that won't work
> > for
> > > plugman projects. homedir may address some use-cases, but
> > project-specific
> > > local registry is still important I think. So... Maybe for CLI
> projects,
> > we
> > > put it in .cordova/config.json and for plugman you use a
> > > --localregistry=FILE flag?
> > >
> >
>

Re: Registry based plugins and tags

[David Kemp <dr...@google.com>]

+1 for project specific registry (not home dir)


On Thu, Sep 19, 2013 at 2:59 PM, Braden Shepherdson <br...@chromium.org>wrote:

> One alternative is to symlink it into $HOME/.plugman/cache/my.plugin.id.
> Then plugman when fetching it will use that, assuming the version is new
> enough. I think the right place for the file is in
> ~/.plugman/localRegistry.json or similar, since fetching plugins is
> definitely plugman's responsibility and not CLI's.
>
> Braden
>
>
> On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > The logic is:
> > - If there's a url, use it, otherwise use the registry.
> >
> > If I'm developing on a plugin, and that plugin has a dependency, I don't
> > want it fetching it from the registry. I could change the <dependency> to
> > have a url= to the local path, but then I need to remember to take that
> out
> > before publishing.
> >
> > So... I'm thinking it would be useful to allow projects to provide their
> > own file-backed local registry. E.g. a JSON file of pluginId -> url/path.
> > Where the new algorithm would be:
> >
> > if id in localRegistry, use that url, otherwise, use the registry.
> >
> > I think this will be super useful for projects that want to distribute
> > plugins off-registry as well.
> >
> > Question is - where's the best place for this?
> >
> > My first thought was in CLI's .cordova/config.json, but that won't work
> for
> > plugman projects. homedir may address some use-cases, but
> project-specific
> > local registry is still important I think. So... Maybe for CLI projects,
> we
> > put it in .cordova/config.json and for plugman you use a
> > --localregistry=FILE flag?
> >
>

Re: Registry based plugins and tags

[Braden Shepherdson <br...@chromium.org>]

One alternative is to symlink it into $HOME/.plugman/cache/my.plugin.id.
Then plugman when fetching it will use that, assuming the version is new
enough. I think the right place for the file is in
~/.plugman/localRegistry.json or similar, since fetching plugins is
definitely plugman's responsibility and not CLI's.

Braden


On Thu, Sep 19, 2013 at 2:56 PM, Andrew Grieve <ag...@chromium.org> wrote:

> The logic is:
> - If there's a url, use it, otherwise use the registry.
>
> If I'm developing on a plugin, and that plugin has a dependency, I don't
> want it fetching it from the registry. I could change the <dependency> to
> have a url= to the local path, but then I need to remember to take that out
> before publishing.
>
> So... I'm thinking it would be useful to allow projects to provide their
> own file-backed local registry. E.g. a JSON file of pluginId -> url/path.
> Where the new algorithm would be:
>
> if id in localRegistry, use that url, otherwise, use the registry.
>
> I think this will be super useful for projects that want to distribute
> plugins off-registry as well.
>
> Question is - where's the best place for this?
>
> My first thought was in CLI's .cordova/config.json, but that won't work for
> plugman projects. homedir may address some use-cases, but project-specific
> local registry is still important I think. So... Maybe for CLI projects, we
> put it in .cordova/config.json and for plugman you use a
> --localregistry=FILE flag?
>

Re: Registry based plugins and tags

[Jesse <pu...@gmail.com>]

npm must have some way of doing this.  ie. some combination of link+install
that resolves dependencies locally.

@purplecabbage
risingj.com


On Thu, Sep 19, 2013 at 11:56 AM, Andrew Grieve <ag...@chromium.org>wrote:

> The logic is:
> - If there's a url, use it, otherwise use the registry.
>
> If I'm developing on a plugin, and that plugin has a dependency, I don't
> want it fetching it from the registry. I could change the <dependency> to
> have a url= to the local path, but then I need to remember to take that out
> before publishing.
>
> So... I'm thinking it would be useful to allow projects to provide their
> own file-backed local registry. E.g. a JSON file of pluginId -> url/path.
> Where the new algorithm would be:
>
> if id in localRegistry, use that url, otherwise, use the registry.
>
> I think this will be super useful for projects that want to distribute
> plugins off-registry as well.
>
> Question is - where's the best place for this?
>
> My first thought was in CLI's .cordova/config.json, but that won't work for
> plugman projects. homedir may address some use-cases, but project-specific
> local registry is still important I think. So... Maybe for CLI projects, we
> put it in .cordova/config.json and for plugman you use a
> --localregistry=FILE flag?
>