You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jeffrey Heifetz <jh...@blackberry.com> on 2013/09/04 03:38:12 UTC

Non-Git Plugin Dependencies

We were working on a redistribution of Cordova that included some plugins and ran into a use-case not covered by the current plugin spec.[1]

Currently there are two ways to specify a dependency
1. Using a combination of url, commit and subdir which plugman will use to clone down a repo and install
2. Set the url to ".", skip the commit and specify a subdir relative to the root of the repo. Plugman then runs git-rev parse to find the root and install from there.

I would like to propose a third way which would be relative to the current install and not use git at all
3. Skip the url, skip the commit and specify a subdir relative to the current plugin.xml.

This would allow us to distribute a version of cordova with plugins to anyone without an unnecessary requirement on git (considering the plugins are fully installed)



1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: Non-Git Plugin Dependencies

Posted by Andrew Grieve <ag...@chromium.org>.
I think either is fine. Note that as of last week, it is fine to use
url#branch:subdir in dependency url values.


On Mon, Sep 9, 2013 at 1:06 PM, Anis KADRI <an...@gmail.com> wrote:

> I don't mind that but I think we should start relying on our registry
> from now on. It's so much simpler to specify a name and a version than
> a long url, branch and subpath. I will write tests for this specific
> case this week.
>
> On Mon, Sep 9, 2013 at 9:05 AM, Jeffrey Heifetz <jh...@blackberry.com>
> wrote:
> > So it seems I killed all discussion here, but before I did that I feel we
> > reached a consensus that relative dependencies are something we'd like to
> > support. The final decision to make is how we would like to do so.
> >
> > Current Implementation <dependency id url commit subdir />. When url =
> "."
> > then the dependency is treated as living in a git repo and the path is
> > <gitRoot>/subdir
> >
> > Proposal 1:
> > When url is missing entirely then the dependency is treated as
> file-system
> > relative and the the path is <current plugin.xml>/subdir
> >
> > Proposal #2 We update the dependency element to <dependency
> > src=url#branch:subdir>. If you want a git relative path then url = "."
> and
> > for file-system relative url != "." and does not have "://"
> >
> > Does this seem correct to everyone? Does anyone have any strong opinions
> > one way or the other?
> >
> >
> > On 13-09-04 4:18 PM, "Jeffrey Heifetz" <jh...@blackberry.com> wrote:
> >
> >>While I believe we could be able to specify everything with a single
> >>parameter, I don't follow what problem we're trying to solve by doing so.
> >>
> >>If I understand everything correctly we're comparing the following;
> >>   <dependency src=url#branch:subdir />
> >>   <dependency url=url commit=branch subdir=subdir />
> >>
> >>While both seem reasonable and I do like the first, this seems
> >>unnecessary.
> >>
> >>On 13-09-04 3:18 PM, "Braden Shepherdson" <br...@chromium.org> wrote:
> >>
> >>>Not quite, since the checked-out directories generally don't have the
> >>>".git" suffix; you'd have to override git's normal naming behavior when
> >>>cloning these.
> >>>
> >>>I think that's quite a bit of delicate magic we don't need. I think src
> >>>might be a better name, if we wanted to go with a single parameter.
> >>>
> >>>If we want to go with two, I like url and path. Supplying both and
> >>>choosing
> >>>based on where the parent plugin was fetched from, that would probably
> >>>work.
> >>>
> >>>I think src="" and my three use cases above works. Thoughts?
> >>>
> >>>Braden
> >>>
> >>>
> >>>On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <ag...@chromium.org>
> >>>wrote:
> >>>
> >>>> Here's another use-case:
> >>>> - You have a github account
> >>>> - You have one plugin per repo
> >>>> - URLs look like: https://github.com/MobileChromeApps/AppBundle.git
> >>>> - You want AppBundle to depend on
> >>>> https://github.com/MobileChromeApps/zip.git
> >>>> - You want this to work when you've got your plugins checked out for
> >>>>local
> >>>> dev:
> >>>> plugins/AppBundle.git
> >>>> plugins/zip.git
> >>>>
> >>>> You try <dependency src="zip.git" />
> >>>>
> >>>> If we treated this as a relative URL, then it would actually work in
> >>>>both
> >>>> cases (online or checked out). If we treat non-absolute-urls as
> >>>>subdirs,
> >>>> then things don't work out for this use-case. If we use path= for
> >>>>subdirs
> >>>> and url= for repo URLs, then both use-cases work out.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mm...@chromium.org>
> >>>>wrote:
> >>>>
> >>>>> I'm not convinced that all use cases cannot be handled with a single
> >>>>> attribute.  Maybe url / path are the wrong names, maybe a single
> >>>>>src="".
> >>>>>
> >>>>>
> >>>>> On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson
> >>>>><br...@chromium.org>wrote:
> >>>>>
> >>>>>> Sure, I can work with path="" instead. What happens if (when) a user
> >>>>>> supplies both?
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve
> >>>>>><ag...@chromium.org>wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <
> >>>>>>> braden@chromium.org> wrote:
> >>>>>>>
> >>>>>>>> I believe the current logic is "a plugin with this ID is already
> >>>>>>>> installed, so stop". That interacts badly with different versions.
> >>>>>>>>
> >>>>>>>> Braden
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny
> >>>>>>>><mm...@chromium.org>wrote:
> >>>>>>>>
> >>>>>>>>> .. but either way if we add support for filesystem-relative paths
> >>>>>>>>>and
> >>>>>>>>> they work when fetching the original plugin either from git or
> >>>>>>>>>locally,
> >>>>>>>>> then we are done.
> >>>>>>>>>
> >>>>>>>>> As an aside, when a plugin lists its dependency as explicitly
> from
> >>>>>>>>>a
> >>>>>>>>> git url, can the user somehow override that to install from a
> >>>>>>>>>local copy?
> >>>>>>>>>  Perhaps if they manually install the dependant first, then we
> >>>>>>>>>won't go
> >>>>>>>>> fetch from git needlessly?  How does that interact with different
> >>>>>>>>>versions
> >>>>>>>>> of the plugin?
> >>>>>>>>>
> >>>>>>>>> -Michal
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny
> >>>>>>>>><mm...@chromium.org>wrote:
> >>>>>>>>>
> >>>>>>>>>> Jeffrey's point at the start of this thread is that he isn't
> >>>>>>>>>>using a
> >>>>>>>>>> git repo locally, so there is no .git folder to find.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
> >>>>>>>>>> braden@chromium.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I like where this is generally going, but I want to correct one
> >>>>>>>>>>> mistake Michal made. There /is/ a way to know which directory
> >>>>>>>>>>>above a
> >>>>>>>>>>> plugin is the root. The code uses git to find the .git
> >>>>>>>>>>>directory, which is
> >>>>>>>>>>> taken to be the root from which the subdir is relative. That
> >>>>>>>>>>>means that in
> >>>>>>>>>>> the case of url="." and url="https://github.com/..." the
> subdir
> >>>>>>>>>>> has the same meaning: relative to the git root.
> >>>>>>>>>>>
> >>>>>>>>>>> I like the path="" option. I agree that subdir and ref could be
> >>>>>>>>>>> dropped, since they can be specified as part of the URL. On the
> >>>>>>>>>>>other hand,
> >>>>>>>>>>> there's no harm in keeping them around for compatibility.
> >>>>>>>>>>>
> >>>>>>>>>>> I suggest:
> >>>>>>>>>>>
> >>>>>>>>>>> 1. Remote git, all in URL: url="
> >>>>>>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
> >>>>>>>>>>>  2. Remote git, separate parameters: url="
> >>>>>>>>>>> https://github.com/foo/bar.git" subdir="sub/dir"
> >>>>>>>>>>>ref="somebranch"
> >>>>>>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir"
> >>>>>>>>>>> ref="somebranch"      (we can probably support all-in-URL here
> >>>>>>>>>>>too)
> >>>>>>>>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no
> >>>>>>>>>>> all-in-URL here; there's no need for the other parameters in
> >>>>>>>>>>>this case)
> >>>>>>>>>>>
> >>>>>>>>>>> The last can be differentiated from the others easily enough,
> >>>>>>>>>>>the
> >>>>>>>>>>> logic is:
> >>>>>>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a
> >>>>>>>>>>> remote git. This is already supported fully.
> >>>>>>>>>>> 2. Is the url === "."? If so, it's a local git-relative path.
> >>>>>>>>>>> Already fully supported.
> >>>>>>>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new
> >>>>>>>>>>> plugin can be found at path.resolve(path_to_current_plugin,
> >>>>>>>>>>> dep.attrib.url); Though some path-separator tweaking is always
> >>>>>>>>>>>required.
> >>>>>>>>>>>
> >>>>>>>>>> I think this will be confusing. For case #3, you have the "url"
> >>>>>>> attribute that defines the path, and not the url. I would look at
> >>>>>>>this and
> >>>>>>> interpret it as a relative URL, and the URL is meant to tell you
> >>>>>>>where the
> >>>>>>> git repo is. It would be much clearer to call this "path" instead
> of
> >>>>>>>"url"
> >>>>>>> for #3 I think.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>> (Re: paths, all paths in plugin.xml should be specified to use
> /
> >>>>>>>>>>> always, URLs and filesystem paths both. It's the tool's job to
> >>>>>>>>>>>properly
> >>>>>>>>>>> split and convert to Windows backslashes where appropriate. I'm
> >>>>>>>>>>>sure there
> >>>>>>>>>>> are a few places where we've gotten this wrong; Windows users
> >>>>>>>>>>>please file
> >>>>>>>>>>> bugs if you run into them. Mostly, though, I was careful to
> >>>>>>>>>>>split/join
> >>>>>>>>>>> explicitly on / or use path.foo functions appropriately.)
> >>>>>>>>>>>
> >>>>>>>>>>> Thoughts on that proposal?
> >>>>>>>>>>>
> >>>>>>>>>>> Braden
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny
> >>>>>>>>>>><mm...@chromium.org>wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> For now, yes, but we could extend that without breaking
> >>>>>>>>>>>>anything,
> >>>>>>>>>>>> no?
> >>>>>>>>>>>>  Right now url="../etc" would be invalid, so we could safely
> >>>>>>>>>>>>add
> >>>>>>>>>>>> support
> >>>>>>>>>>>> for urls with leading "..", and make that relative to current
> >>>>>>>>>>>> plugin.
> >>>>>>>>>>>>
> >>>>>>>>>>>> url="." would still do what it does today, but could likely be
> >>>>>>>>>>>> deprecated
> >>>>>>>>>>>> along with subdir and commit attributes (or at least document
> >>>>>>>>>>>>the
> >>>>>>>>>>>> limitation of that approach somewhere).
> >>>>>>>>>>>>
> >>>>>>>>>>>> Not sure about making the form url="./etc" be relative to URL
> >>>>>>>>>>>>root
> >>>>>>>>>>>> or
> >>>>>>>>>>>> current plugin, but I don't see why that form would ever be
> >>>>>>>>>>>>useful
> >>>>>>>>>>>> anyway.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -Michal
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <
> >>>>>>>>>>>> agrieve@chromium.org> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> > Because for the hosted case, the URL points to where the
> repo
> >>>>>>>>>>>> is, not to
> >>>>>>>>>>>> > where the plugin is.
> >>>>>>>>>>>> >
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <
> >>>>>>>>>>>> mmocny@chromium.org> wrote:
> >>>>>>>>>>>> >
> >>>>>>>>>>>> >> If URL can be relative, why do we need a new path
> parameter?
> >>>>>>>>>>>>  All we
> >>>>>>>>>>>> >> would need is to treat leading ./ or ../ as relative to the
> >>>>>>>>>>>> plugin not
> >>>>>>>>>>>> >> root, which I think is fine.
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to
> >>>>>>>>>>>>make
> >>>>>>>>>>>> sure all
> >>>>>>>>>>>> >> the cases are handled.
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
> >>>>>>>>>>>> agrieve@chromium.org>wrote:
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >>> Agree the use-case is valid. Here's a variation on (1)
> that
> >>>>>>>>>>>>I
> >>>>>>>>>>>> think is
> >>>>>>>>>>>> >>> marginally nicer:
> >>>>>>>>>>>> >>>
> >>>>>>>>>>>> >>> url="." to be made optional, but default value is "."
> >>>>>>>>>>>> >>> subdir="" works only with git repos and is always relative
> >>>>>>>>>>>>to
> >>>>>>>>>>>> the root
> >>>>>>>>>>>> >>> of the repo.
> >>>>>>>>>>>> >>> path="" works with git repos or local paths and is
> relative
> >>>>>>>>>>>>to
> >>>>>>>>>>>> the
> >>>>>>>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or
> >>>>>>>>>>>> "subdir" if you
> >>>>>>>>>>>> >>> have "path".
> >>>>>>>>>>>> >>>
> >>>>>>>>>>>> >>> Support was just added for specifying commit and path
> >>>>>>>>>>>>within
> >>>>>>>>>>>> url. So, we
> >>>>>>>>>>>> >>> could actually just deprecate "subdir". and have "url" or
> >>>>>>>>>>>> "path"
> >>>>>>>>>>>> >>>
> >>>>>>>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative
> >>>>>>>>>>>>to
> >>>>>>>>>>>> the
> >>>>>>>>>>>> >>> current plugin's git url.
> >>>>>>>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current
> >>>>>>>>>>>>URL
> >>>>>>>>>>>> >>> (cordova-labs style)
> >>>>>>>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on
> >>>>>>>>>>>>the
> >>>>>>>>>>>> current URL
> >>>>>>>>>>>> >>> plus a subdir within it.
> >>>>>>>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you
> >>>>>>>>>>>> just want to
> >>>>>>>>>>>> >>> set the path)
> >>>>>>>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the
> >>>>>>>>>>>>current
> >>>>>>>>>>>> plugin is
> >>>>>>>>>>>> >>> from git, then be careful not to go above the git root.
> >>>>>>>>>>>> >>>
> >>>>>>>>>>>> >>>
> >>>>>>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <
> >>>>>>>>>>>> mmocny@chromium.org>wrote:
> >>>>>>>>>>>> >>>
> >>>>>>>>>>>> >>>> Mulling this over a bit, I think I would like a solution
> >>>>>>>>>>>>for
> >>>>>>>>>>>> specifying
> >>>>>>>>>>>> >>>> dependancies that would work regardless of where/how the
> >>>>>>>>>>>> plugins are
> >>>>>>>>>>>> >>>> hosted, git or local.  If you had:
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> BB_PLUGINS/
> >>>>>>>>>>>> >>>> - plug1/
> >>>>>>>>>>>> >>>> - plug2/
> >>>>>>>>>>>> >>>> ...
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> (and plug1 depends on plug2), then:
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1
> >>>>>>>>>>>>..and..
> >>>>>>>>>>>>   cordova
> >>>>>>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> ..should both work without changing all of the dependency
> >>>>>>>>>>>> tags in plug1.
> >>>>>>>>>>>> >>>>  Actually, the plugin author should not have an explicit
> >>>>>>>>>>>>say
> >>>>>>>>>>>> in how a
> >>>>>>>>>>>> >>>> user
> >>>>>>>>>>>> >>>> manages these directories (except in the directory
> >>>>>>>>>>>> structure).  Note
> >>>>>>>>>>>> >>>> that
> >>>>>>>>>>>> >>>> this situation applies whenever a user clones your plugin
> >>>>>>>>>>>> repo to
> >>>>>>>>>>>> >>>> locally,
> >>>>>>>>>>>> >>>> or for the reverse direction, when ever they add your
> >>>>>>>>>>>>plugins
> >>>>>>>>>>>> into their
> >>>>>>>>>>>> >>>> teams' git repo.
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> Right now, thats not possible, because when installing
> >>>>>>>>>>>>from
> >>>>>>>>>>>> local path
> >>>>>>>>>>>> >>>> with
> >>>>>>>>>>>> >>>> url="." there is no way to know which of the plugins
> >>>>>>>>>>>>parent
> >>>>>>>>>>>> directories
> >>>>>>>>>>>> >>>> to
> >>>>>>>>>>>> >>>> consider as the "root".  We could resolve this using
> >>>>>>>>>>>>several
> >>>>>>>>>>>> ways, among
> >>>>>>>>>>>> >>>> them:
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path
> >>>>>>>>>>>> relative to this
> >>>>>>>>>>>> >>>> plugin" (note however, that I propose it also works when
> >>>>>>>>>>>> installing
> >>>>>>>>>>>> >>>> from a
> >>>>>>>>>>>> >>>> git repo).  Deprecate/warn against using url=".".
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> (2) Support a new special file to "mark" the plugin root
> >>>>>>>>>>>>dir
> >>>>>>>>>>>> so we can
> >>>>>>>>>>>> >>>> walk
> >>>>>>>>>>>> >>>> the directory tree to find the valid target for url="."
> >>>>>>>>>>>>(ie,
> >>>>>>>>>>>> replace the
> >>>>>>>>>>>> >>>> requirement for a .git with a requirement for a
> >>>>>>>>>>>> .cordova_repo, which BB
> >>>>>>>>>>>> >>>> and
> >>>>>>>>>>>> >>>> others could place within their plugin bundle).
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> I like (1).
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> -Michal
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <
> >>>>>>>>>>>> mmocny@chromium.org>
> >>>>>>>>>>>> >>>> wrote:
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>> > Sounds reasonable to me.
> >>>>>>>>>>>> >>>> >
> >>>>>>>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2)
> >>>>>>>>>>>>shouldn't
> >>>>>>>>>>>> do what
> >>>>>>>>>>>> >>>> you
> >>>>>>>>>>>> >>>> > request when the url for the original plugin was a
> local
> >>>>>>>>>>>> path?  Maybe
> >>>>>>>>>>>> >>>> just
> >>>>>>>>>>>> >>>> > a bug?
> >>>>>>>>>>>> >>>> >
> >>>>>>>>>>>> >>>> > -Michal
> >>>>>>>>>>>> >>>> >
> >>>>>>>>>>>> >>>> >
> >>>>>>>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
> >>>>>>>>>>>> >>>> jheifetz@blackberry.com>wrote:
> >>>>>>>>>>>> >>>> >
> >>>>>>>>>>>> >>>> >> We were working on a redistribution of Cordova that
> >>>>>>>>>>>> included some
> >>>>>>>>>>>> >>>> plugins
> >>>>>>>>>>>> >>>> >> and ran into a use-case not covered by the current
> >>>>>>>>>>>>plugin
> >>>>>>>>>>>> spec.[1]
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>> >>>> >> Currently there are two ways to specify a dependency
> >>>>>>>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which
> >>>>>>>>>>>> plugman will
> >>>>>>>>>>>> >>>> use
> >>>>>>>>>>>> >>>> >> to clone down a repo and install
> >>>>>>>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a
> >>>>>>>>>>>> subdir relative
> >>>>>>>>>>>> >>>> to
> >>>>>>>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse
> >>>>>>>>>>>>to
> >>>>>>>>>>>> find the
> >>>>>>>>>>>> >>>> root and
> >>>>>>>>>>>> >>>> >> install from there.
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>> >>>> >> I would like to propose a third way which would be
> >>>>>>>>>>>> relative to the
> >>>>>>>>>>>> >>>> >> current install and not use git at all
> >>>>>>>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir
> >>>>>>>>>>>> relative to the
> >>>>>>>>>>>> >>>> >> current plugin.xml.
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>> >>>> >> This would allow us to distribute a version of cordova
> >>>>>>>>>>>> with plugins
> >>>>>>>>>>>> >>>> to
> >>>>>>>>>>>> >>>> >> anyone without an unnecessary requirement on git
> >>>>>>>>>>>> (considering the
> >>>>>>>>>>>> >>>> plugins
> >>>>>>>>>>>> >>>> >> are fully installed)
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>> >>>> >> 1.
> >>>>>>>>>>>>
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>>
>
> >>>>>>>>>>>>----------------------------------------------------------------
> >>>>>>>>>>>>-
> >>>>>>>>>>>>----
> >>>>>>>>>>>> >>>> >> This transmission (including any attachments) may
> >>>>>>>>>>>>contain
> >>>>>>>>>>>> >>>> confidential
> >>>>>>>>>>>> >>>> >> information, privileged material (including material
> >>>>>>>>>>>> protected by the
> >>>>>>>>>>>> >>>> >> solicitor-client or other applicable privileges), or
> >>>>>>>>>>>> constitute
> >>>>>>>>>>>> >>>> non-public
> >>>>>>>>>>>> >>>> >> information. Any use of this information by anyone
> >>>>>>>>>>>>other
> >>>>>>>>>>>> than the
> >>>>>>>>>>>> >>>> intended
> >>>>>>>>>>>> >>>> >> recipient is prohibited. If you have received this
> >>>>>>>>>>>> transmission in
> >>>>>>>>>>>> >>>> error,
> >>>>>>>>>>>> >>>> >> please immediately reply to the sender and delete this
> >>>>>>>>>>>> information
> >>>>>>>>>>>> >>>> from
> >>>>>>>>>>>> >>>> >> your system. Use, dissemination, distribution, or
> >>>>>>>>>>>> reproduction of
> >>>>>>>>>>>> >>>> this
> >>>>>>>>>>>> >>>> >> transmission by unintended recipients is not
> authorized
> >>>>>>>>>>>> and may be
> >>>>>>>>>>>> >>>> unlawful.
> >>>>>>>>>>>> >>>> >>
> >>>>>>>>>>>> >>>> >
> >>>>>>>>>>>> >>>> >
> >>>>>>>>>>>> >>>>
> >>>>>>>>>>>> >>>
> >>>>>>>>>>>> >>>
> >>>>>>>>>>>> >>
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
> >>---------------------------------------------------------------------
> >>This transmission (including any attachments) may contain confidential
> >>information, privileged material (including material protected by the
> >>solicitor-client or other applicable privileges), or constitute
> >>non-public information. Any use of this information by anyone other than
> >>the intended recipient is prohibited. If you have received this
> >>transmission in error, please immediately reply to the sender and delete
> >>this information from your system. Use, dissemination, distribution, or
> >>reproduction of this transmission by unintended recipients is not
> >>authorized and may be unlawful.
> >
> >
> > ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

Re: Non-Git Plugin Dependencies

Posted by Anis KADRI <an...@gmail.com>.
I don't mind that but I think we should start relying on our registry
from now on. It's so much simpler to specify a name and a version than
a long url, branch and subpath. I will write tests for this specific
case this week.

On Mon, Sep 9, 2013 at 9:05 AM, Jeffrey Heifetz <jh...@blackberry.com> wrote:
> So it seems I killed all discussion here, but before I did that I feel we
> reached a consensus that relative dependencies are something we'd like to
> support. The final decision to make is how we would like to do so.
>
> Current Implementation <dependency id url commit subdir />. When url = "."
> then the dependency is treated as living in a git repo and the path is
> <gitRoot>/subdir
>
> Proposal 1:
> When url is missing entirely then the dependency is treated as file-system
> relative and the the path is <current plugin.xml>/subdir
>
> Proposal #2 We update the dependency element to <dependency
> src=url#branch:subdir>. If you want a git relative path then url = "." and
> for file-system relative url != "." and does not have "://"
>
> Does this seem correct to everyone? Does anyone have any strong opinions
> one way or the other?
>
>
> On 13-09-04 4:18 PM, "Jeffrey Heifetz" <jh...@blackberry.com> wrote:
>
>>While I believe we could be able to specify everything with a single
>>parameter, I don't follow what problem we're trying to solve by doing so.
>>
>>If I understand everything correctly we're comparing the following;
>>   <dependency src=url#branch:subdir />
>>   <dependency url=url commit=branch subdir=subdir />
>>
>>While both seem reasonable and I do like the first, this seems
>>unnecessary.
>>
>>On 13-09-04 3:18 PM, "Braden Shepherdson" <br...@chromium.org> wrote:
>>
>>>Not quite, since the checked-out directories generally don't have the
>>>".git" suffix; you'd have to override git's normal naming behavior when
>>>cloning these.
>>>
>>>I think that's quite a bit of delicate magic we don't need. I think src
>>>might be a better name, if we wanted to go with a single parameter.
>>>
>>>If we want to go with two, I like url and path. Supplying both and
>>>choosing
>>>based on where the parent plugin was fetched from, that would probably
>>>work.
>>>
>>>I think src="" and my three use cases above works. Thoughts?
>>>
>>>Braden
>>>
>>>
>>>On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <ag...@chromium.org>
>>>wrote:
>>>
>>>> Here's another use-case:
>>>> - You have a github account
>>>> - You have one plugin per repo
>>>> - URLs look like: https://github.com/MobileChromeApps/AppBundle.git
>>>> - You want AppBundle to depend on
>>>> https://github.com/MobileChromeApps/zip.git
>>>> - You want this to work when you've got your plugins checked out for
>>>>local
>>>> dev:
>>>> plugins/AppBundle.git
>>>> plugins/zip.git
>>>>
>>>> You try <dependency src="zip.git" />
>>>>
>>>> If we treated this as a relative URL, then it would actually work in
>>>>both
>>>> cases (online or checked out). If we treat non-absolute-urls as
>>>>subdirs,
>>>> then things don't work out for this use-case. If we use path= for
>>>>subdirs
>>>> and url= for repo URLs, then both use-cases work out.
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mm...@chromium.org>
>>>>wrote:
>>>>
>>>>> I'm not convinced that all use cases cannot be handled with a single
>>>>> attribute.  Maybe url / path are the wrong names, maybe a single
>>>>>src="".
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson
>>>>><br...@chromium.org>wrote:
>>>>>
>>>>>> Sure, I can work with path="" instead. What happens if (when) a user
>>>>>> supplies both?
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve
>>>>>><ag...@chromium.org>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <
>>>>>>> braden@chromium.org> wrote:
>>>>>>>
>>>>>>>> I believe the current logic is "a plugin with this ID is already
>>>>>>>> installed, so stop". That interacts badly with different versions.
>>>>>>>>
>>>>>>>> Braden
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny
>>>>>>>><mm...@chromium.org>wrote:
>>>>>>>>
>>>>>>>>> .. but either way if we add support for filesystem-relative paths
>>>>>>>>>and
>>>>>>>>> they work when fetching the original plugin either from git or
>>>>>>>>>locally,
>>>>>>>>> then we are done.
>>>>>>>>>
>>>>>>>>> As an aside, when a plugin lists its dependency as explicitly from
>>>>>>>>>a
>>>>>>>>> git url, can the user somehow override that to install from a
>>>>>>>>>local copy?
>>>>>>>>>  Perhaps if they manually install the dependant first, then we
>>>>>>>>>won't go
>>>>>>>>> fetch from git needlessly?  How does that interact with different
>>>>>>>>>versions
>>>>>>>>> of the plugin?
>>>>>>>>>
>>>>>>>>> -Michal
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny
>>>>>>>>><mm...@chromium.org>wrote:
>>>>>>>>>
>>>>>>>>>> Jeffrey's point at the start of this thread is that he isn't
>>>>>>>>>>using a
>>>>>>>>>> git repo locally, so there is no .git folder to find.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
>>>>>>>>>> braden@chromium.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> I like where this is generally going, but I want to correct one
>>>>>>>>>>> mistake Michal made. There /is/ a way to know which directory
>>>>>>>>>>>above a
>>>>>>>>>>> plugin is the root. The code uses git to find the .git
>>>>>>>>>>>directory, which is
>>>>>>>>>>> taken to be the root from which the subdir is relative. That
>>>>>>>>>>>means that in
>>>>>>>>>>> the case of url="." and url="https://github.com/..." the subdir
>>>>>>>>>>> has the same meaning: relative to the git root.
>>>>>>>>>>>
>>>>>>>>>>> I like the path="" option. I agree that subdir and ref could be
>>>>>>>>>>> dropped, since they can be specified as part of the URL. On the
>>>>>>>>>>>other hand,
>>>>>>>>>>> there's no harm in keeping them around for compatibility.
>>>>>>>>>>>
>>>>>>>>>>> I suggest:
>>>>>>>>>>>
>>>>>>>>>>> 1. Remote git, all in URL: url="
>>>>>>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>>>>>>>>  2. Remote git, separate parameters: url="
>>>>>>>>>>> https://github.com/foo/bar.git" subdir="sub/dir"
>>>>>>>>>>>ref="somebranch"
>>>>>>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir"
>>>>>>>>>>> ref="somebranch"      (we can probably support all-in-URL here
>>>>>>>>>>>too)
>>>>>>>>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no
>>>>>>>>>>> all-in-URL here; there's no need for the other parameters in
>>>>>>>>>>>this case)
>>>>>>>>>>>
>>>>>>>>>>> The last can be differentiated from the others easily enough,
>>>>>>>>>>>the
>>>>>>>>>>> logic is:
>>>>>>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a
>>>>>>>>>>> remote git. This is already supported fully.
>>>>>>>>>>> 2. Is the url === "."? If so, it's a local git-relative path.
>>>>>>>>>>> Already fully supported.
>>>>>>>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new
>>>>>>>>>>> plugin can be found at path.resolve(path_to_current_plugin,
>>>>>>>>>>> dep.attrib.url); Though some path-separator tweaking is always
>>>>>>>>>>>required.
>>>>>>>>>>>
>>>>>>>>>> I think this will be confusing. For case #3, you have the "url"
>>>>>>> attribute that defines the path, and not the url. I would look at
>>>>>>>this and
>>>>>>> interpret it as a relative URL, and the URL is meant to tell you
>>>>>>>where the
>>>>>>> git repo is. It would be much clearer to call this "path" instead of
>>>>>>>"url"
>>>>>>> for #3 I think.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>>> (Re: paths, all paths in plugin.xml should be specified to use /
>>>>>>>>>>> always, URLs and filesystem paths both. It's the tool's job to
>>>>>>>>>>>properly
>>>>>>>>>>> split and convert to Windows backslashes where appropriate. I'm
>>>>>>>>>>>sure there
>>>>>>>>>>> are a few places where we've gotten this wrong; Windows users
>>>>>>>>>>>please file
>>>>>>>>>>> bugs if you run into them. Mostly, though, I was careful to
>>>>>>>>>>>split/join
>>>>>>>>>>> explicitly on / or use path.foo functions appropriately.)
>>>>>>>>>>>
>>>>>>>>>>> Thoughts on that proposal?
>>>>>>>>>>>
>>>>>>>>>>> Braden
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny
>>>>>>>>>>><mm...@chromium.org>wrote:
>>>>>>>>>>>
>>>>>>>>>>>> For now, yes, but we could extend that without breaking
>>>>>>>>>>>>anything,
>>>>>>>>>>>> no?
>>>>>>>>>>>>  Right now url="../etc" would be invalid, so we could safely
>>>>>>>>>>>>add
>>>>>>>>>>>> support
>>>>>>>>>>>> for urls with leading "..", and make that relative to current
>>>>>>>>>>>> plugin.
>>>>>>>>>>>>
>>>>>>>>>>>> url="." would still do what it does today, but could likely be
>>>>>>>>>>>> deprecated
>>>>>>>>>>>> along with subdir and commit attributes (or at least document
>>>>>>>>>>>>the
>>>>>>>>>>>> limitation of that approach somewhere).
>>>>>>>>>>>>
>>>>>>>>>>>> Not sure about making the form url="./etc" be relative to URL
>>>>>>>>>>>>root
>>>>>>>>>>>> or
>>>>>>>>>>>> current plugin, but I don't see why that form would ever be
>>>>>>>>>>>>useful
>>>>>>>>>>>> anyway.
>>>>>>>>>>>>
>>>>>>>>>>>> -Michal
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <
>>>>>>>>>>>> agrieve@chromium.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> > Because for the hosted case, the URL points to where the repo
>>>>>>>>>>>> is, not to
>>>>>>>>>>>> > where the plugin is.
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <
>>>>>>>>>>>> mmocny@chromium.org> wrote:
>>>>>>>>>>>> >
>>>>>>>>>>>> >> If URL can be relative, why do we need a new path parameter?
>>>>>>>>>>>>  All we
>>>>>>>>>>>> >> would need is to treat leading ./ or ../ as relative to the
>>>>>>>>>>>> plugin not
>>>>>>>>>>>> >> root, which I think is fine.
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to
>>>>>>>>>>>>make
>>>>>>>>>>>> sure all
>>>>>>>>>>>> >> the cases are handled.
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
>>>>>>>>>>>> agrieve@chromium.org>wrote:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>> Agree the use-case is valid. Here's a variation on (1) that
>>>>>>>>>>>>I
>>>>>>>>>>>> think is
>>>>>>>>>>>> >>> marginally nicer:
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> url="." to be made optional, but default value is "."
>>>>>>>>>>>> >>> subdir="" works only with git repos and is always relative
>>>>>>>>>>>>to
>>>>>>>>>>>> the root
>>>>>>>>>>>> >>> of the repo.
>>>>>>>>>>>> >>> path="" works with git repos or local paths and is relative
>>>>>>>>>>>>to
>>>>>>>>>>>> the
>>>>>>>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or
>>>>>>>>>>>> "subdir" if you
>>>>>>>>>>>> >>> have "path".
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> Support was just added for specifying commit and path
>>>>>>>>>>>>within
>>>>>>>>>>>> url. So, we
>>>>>>>>>>>> >>> could actually just deprecate "subdir". and have "url" or
>>>>>>>>>>>> "path"
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative
>>>>>>>>>>>>to
>>>>>>>>>>>> the
>>>>>>>>>>>> >>> current plugin's git url.
>>>>>>>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current
>>>>>>>>>>>>URL
>>>>>>>>>>>> >>> (cordova-labs style)
>>>>>>>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on
>>>>>>>>>>>>the
>>>>>>>>>>>> current URL
>>>>>>>>>>>> >>> plus a subdir within it.
>>>>>>>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you
>>>>>>>>>>>> just want to
>>>>>>>>>>>> >>> set the path)
>>>>>>>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the
>>>>>>>>>>>>current
>>>>>>>>>>>> plugin is
>>>>>>>>>>>> >>> from git, then be careful not to go above the git root.
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <
>>>>>>>>>>>> mmocny@chromium.org>wrote:
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>>> Mulling this over a bit, I think I would like a solution
>>>>>>>>>>>>for
>>>>>>>>>>>> specifying
>>>>>>>>>>>> >>>> dependancies that would work regardless of where/how the
>>>>>>>>>>>> plugins are
>>>>>>>>>>>> >>>> hosted, git or local.  If you had:
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> BB_PLUGINS/
>>>>>>>>>>>> >>>> - plug1/
>>>>>>>>>>>> >>>> - plug2/
>>>>>>>>>>>> >>>> ...
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> (and plug1 depends on plug2), then:
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1
>>>>>>>>>>>>..and..
>>>>>>>>>>>>   cordova
>>>>>>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> ..should both work without changing all of the dependency
>>>>>>>>>>>> tags in plug1.
>>>>>>>>>>>> >>>>  Actually, the plugin author should not have an explicit
>>>>>>>>>>>>say
>>>>>>>>>>>> in how a
>>>>>>>>>>>> >>>> user
>>>>>>>>>>>> >>>> manages these directories (except in the directory
>>>>>>>>>>>> structure).  Note
>>>>>>>>>>>> >>>> that
>>>>>>>>>>>> >>>> this situation applies whenever a user clones your plugin
>>>>>>>>>>>> repo to
>>>>>>>>>>>> >>>> locally,
>>>>>>>>>>>> >>>> or for the reverse direction, when ever they add your
>>>>>>>>>>>>plugins
>>>>>>>>>>>> into their
>>>>>>>>>>>> >>>> teams' git repo.
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> Right now, thats not possible, because when installing
>>>>>>>>>>>>from
>>>>>>>>>>>> local path
>>>>>>>>>>>> >>>> with
>>>>>>>>>>>> >>>> url="." there is no way to know which of the plugins
>>>>>>>>>>>>parent
>>>>>>>>>>>> directories
>>>>>>>>>>>> >>>> to
>>>>>>>>>>>> >>>> consider as the "root".  We could resolve this using
>>>>>>>>>>>>several
>>>>>>>>>>>> ways, among
>>>>>>>>>>>> >>>> them:
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path
>>>>>>>>>>>> relative to this
>>>>>>>>>>>> >>>> plugin" (note however, that I propose it also works when
>>>>>>>>>>>> installing
>>>>>>>>>>>> >>>> from a
>>>>>>>>>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> (2) Support a new special file to "mark" the plugin root
>>>>>>>>>>>>dir
>>>>>>>>>>>> so we can
>>>>>>>>>>>> >>>> walk
>>>>>>>>>>>> >>>> the directory tree to find the valid target for url="."
>>>>>>>>>>>>(ie,
>>>>>>>>>>>> replace the
>>>>>>>>>>>> >>>> requirement for a .git with a requirement for a
>>>>>>>>>>>> .cordova_repo, which BB
>>>>>>>>>>>> >>>> and
>>>>>>>>>>>> >>>> others could place within their plugin bundle).
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> I like (1).
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> -Michal
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <
>>>>>>>>>>>> mmocny@chromium.org>
>>>>>>>>>>>> >>>> wrote:
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>> > Sounds reasonable to me.
>>>>>>>>>>>> >>>> >
>>>>>>>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2)
>>>>>>>>>>>>shouldn't
>>>>>>>>>>>> do what
>>>>>>>>>>>> >>>> you
>>>>>>>>>>>> >>>> > request when the url for the original plugin was a local
>>>>>>>>>>>> path?  Maybe
>>>>>>>>>>>> >>>> just
>>>>>>>>>>>> >>>> > a bug?
>>>>>>>>>>>> >>>> >
>>>>>>>>>>>> >>>> > -Michal
>>>>>>>>>>>> >>>> >
>>>>>>>>>>>> >>>> >
>>>>>>>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>>>>>>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>>>>>>>>> >>>> >
>>>>>>>>>>>> >>>> >> We were working on a redistribution of Cordova that
>>>>>>>>>>>> included some
>>>>>>>>>>>> >>>> plugins
>>>>>>>>>>>> >>>> >> and ran into a use-case not covered by the current
>>>>>>>>>>>>plugin
>>>>>>>>>>>> spec.[1]
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>> >>>> >> Currently there are two ways to specify a dependency
>>>>>>>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which
>>>>>>>>>>>> plugman will
>>>>>>>>>>>> >>>> use
>>>>>>>>>>>> >>>> >> to clone down a repo and install
>>>>>>>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a
>>>>>>>>>>>> subdir relative
>>>>>>>>>>>> >>>> to
>>>>>>>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse
>>>>>>>>>>>>to
>>>>>>>>>>>> find the
>>>>>>>>>>>> >>>> root and
>>>>>>>>>>>> >>>> >> install from there.
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>> >>>> >> I would like to propose a third way which would be
>>>>>>>>>>>> relative to the
>>>>>>>>>>>> >>>> >> current install and not use git at all
>>>>>>>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir
>>>>>>>>>>>> relative to the
>>>>>>>>>>>> >>>> >> current plugin.xml.
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>> >>>> >> This would allow us to distribute a version of cordova
>>>>>>>>>>>> with plugins
>>>>>>>>>>>> >>>> to
>>>>>>>>>>>> >>>> >> anyone without an unnecessary requirement on git
>>>>>>>>>>>> (considering the
>>>>>>>>>>>> >>>> plugins
>>>>>>>>>>>> >>>> >> are fully installed)
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>> >>>> >> 1.
>>>>>>>>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>>
>>>>>>>>>>>>----------------------------------------------------------------
>>>>>>>>>>>>-
>>>>>>>>>>>>----
>>>>>>>>>>>> >>>> >> This transmission (including any attachments) may
>>>>>>>>>>>>contain
>>>>>>>>>>>> >>>> confidential
>>>>>>>>>>>> >>>> >> information, privileged material (including material
>>>>>>>>>>>> protected by the
>>>>>>>>>>>> >>>> >> solicitor-client or other applicable privileges), or
>>>>>>>>>>>> constitute
>>>>>>>>>>>> >>>> non-public
>>>>>>>>>>>> >>>> >> information. Any use of this information by anyone
>>>>>>>>>>>>other
>>>>>>>>>>>> than the
>>>>>>>>>>>> >>>> intended
>>>>>>>>>>>> >>>> >> recipient is prohibited. If you have received this
>>>>>>>>>>>> transmission in
>>>>>>>>>>>> >>>> error,
>>>>>>>>>>>> >>>> >> please immediately reply to the sender and delete this
>>>>>>>>>>>> information
>>>>>>>>>>>> >>>> from
>>>>>>>>>>>> >>>> >> your system. Use, dissemination, distribution, or
>>>>>>>>>>>> reproduction of
>>>>>>>>>>>> >>>> this
>>>>>>>>>>>> >>>> >> transmission by unintended recipients is not authorized
>>>>>>>>>>>> and may be
>>>>>>>>>>>> >>>> unlawful.
>>>>>>>>>>>> >>>> >>
>>>>>>>>>>>> >>>> >
>>>>>>>>>>>> >>>> >
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>>
>>>>>>>>>>>> >>
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>>---------------------------------------------------------------------
>>This transmission (including any attachments) may contain confidential
>>information, privileged material (including material protected by the
>>solicitor-client or other applicable privileges), or constitute
>>non-public information. Any use of this information by anyone other than
>>the intended recipient is prohibited. If you have received this
>>transmission in error, please immediately reply to the sender and delete
>>this information from your system. Use, dissemination, distribution, or
>>reproduction of this transmission by unintended recipients is not
>>authorized and may be unlawful.
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: Non-Git Plugin Dependencies

Posted by Jeffrey Heifetz <jh...@blackberry.com>.
So it seems I killed all discussion here, but before I did that I feel we
reached a consensus that relative dependencies are something we'd like to
support. The final decision to make is how we would like to do so.

Current Implementation <dependency id url commit subdir />. When url = "."
then the dependency is treated as living in a git repo and the path is
<gitRoot>/subdir

Proposal 1:
When url is missing entirely then the dependency is treated as file-system
relative and the the path is <current plugin.xml>/subdir

Proposal #2 We update the dependency element to <dependency
src=url#branch:subdir>. If you want a git relative path then url = "." and
for file-system relative url != "." and does not have "://"

Does this seem correct to everyone? Does anyone have any strong opinions
one way or the other?


On 13-09-04 4:18 PM, "Jeffrey Heifetz" <jh...@blackberry.com> wrote:

>While I believe we could be able to specify everything with a single
>parameter, I don't follow what problem we're trying to solve by doing so.
>
>If I understand everything correctly we're comparing the following;
>   <dependency src=url#branch:subdir />
>   <dependency url=url commit=branch subdir=subdir />
>
>While both seem reasonable and I do like the first, this seems
>unnecessary.
>
>On 13-09-04 3:18 PM, "Braden Shepherdson" <br...@chromium.org> wrote:
>
>>Not quite, since the checked-out directories generally don't have the
>>".git" suffix; you'd have to override git's normal naming behavior when
>>cloning these.
>>
>>I think that's quite a bit of delicate magic we don't need. I think src
>>might be a better name, if we wanted to go with a single parameter.
>>
>>If we want to go with two, I like url and path. Supplying both and
>>choosing
>>based on where the parent plugin was fetched from, that would probably
>>work.
>>
>>I think src="" and my three use cases above works. Thoughts?
>>
>>Braden
>>
>>
>>On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <ag...@chromium.org>
>>wrote:
>>
>>> Here's another use-case:
>>> - You have a github account
>>> - You have one plugin per repo
>>> - URLs look like: https://github.com/MobileChromeApps/AppBundle.git
>>> - You want AppBundle to depend on
>>> https://github.com/MobileChromeApps/zip.git
>>> - You want this to work when you've got your plugins checked out for
>>>local
>>> dev:
>>> plugins/AppBundle.git
>>> plugins/zip.git
>>>
>>> You try <dependency src="zip.git" />
>>>
>>> If we treated this as a relative URL, then it would actually work in
>>>both
>>> cases (online or checked out). If we treat non-absolute-urls as
>>>subdirs,
>>> then things don't work out for this use-case. If we use path= for
>>>subdirs
>>> and url= for repo URLs, then both use-cases work out.
>>>
>>>
>>>
>>>
>>> On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mm...@chromium.org>
>>>wrote:
>>>
>>>> I'm not convinced that all use cases cannot be handled with a single
>>>> attribute.  Maybe url / path are the wrong names, maybe a single
>>>>src="".
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson
>>>><br...@chromium.org>wrote:
>>>>
>>>>> Sure, I can work with path="" instead. What happens if (when) a user
>>>>> supplies both?
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve
>>>>><ag...@chromium.org>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <
>>>>>> braden@chromium.org> wrote:
>>>>>>
>>>>>>> I believe the current logic is "a plugin with this ID is already
>>>>>>> installed, so stop". That interacts badly with different versions.
>>>>>>>
>>>>>>> Braden
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny
>>>>>>><mm...@chromium.org>wrote:
>>>>>>>
>>>>>>>> .. but either way if we add support for filesystem-relative paths
>>>>>>>>and
>>>>>>>> they work when fetching the original plugin either from git or
>>>>>>>>locally,
>>>>>>>> then we are done.
>>>>>>>>
>>>>>>>> As an aside, when a plugin lists its dependency as explicitly from
>>>>>>>>a
>>>>>>>> git url, can the user somehow override that to install from a
>>>>>>>>local copy?
>>>>>>>>  Perhaps if they manually install the dependant first, then we
>>>>>>>>won't go
>>>>>>>> fetch from git needlessly?  How does that interact with different
>>>>>>>>versions
>>>>>>>> of the plugin?
>>>>>>>>
>>>>>>>> -Michal
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny
>>>>>>>><mm...@chromium.org>wrote:
>>>>>>>>
>>>>>>>>> Jeffrey's point at the start of this thread is that he isn't
>>>>>>>>>using a
>>>>>>>>> git repo locally, so there is no .git folder to find.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
>>>>>>>>> braden@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>>> I like where this is generally going, but I want to correct one
>>>>>>>>>> mistake Michal made. There /is/ a way to know which directory
>>>>>>>>>>above a
>>>>>>>>>> plugin is the root. The code uses git to find the .git
>>>>>>>>>>directory, which is
>>>>>>>>>> taken to be the root from which the subdir is relative. That
>>>>>>>>>>means that in
>>>>>>>>>> the case of url="." and url="https://github.com/..." the subdir
>>>>>>>>>> has the same meaning: relative to the git root.
>>>>>>>>>>
>>>>>>>>>> I like the path="" option. I agree that subdir and ref could be
>>>>>>>>>> dropped, since they can be specified as part of the URL. On the
>>>>>>>>>>other hand,
>>>>>>>>>> there's no harm in keeping them around for compatibility.
>>>>>>>>>>
>>>>>>>>>> I suggest:
>>>>>>>>>>
>>>>>>>>>> 1. Remote git, all in URL: url="
>>>>>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>>>>>>>  2. Remote git, separate parameters: url="
>>>>>>>>>> https://github.com/foo/bar.git" subdir="sub/dir"
>>>>>>>>>>ref="somebranch"
>>>>>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir"
>>>>>>>>>> ref="somebranch"      (we can probably support all-in-URL here
>>>>>>>>>>too)
>>>>>>>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no
>>>>>>>>>> all-in-URL here; there's no need for the other parameters in
>>>>>>>>>>this case)
>>>>>>>>>>
>>>>>>>>>> The last can be differentiated from the others easily enough,
>>>>>>>>>>the
>>>>>>>>>> logic is:
>>>>>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a
>>>>>>>>>> remote git. This is already supported fully.
>>>>>>>>>> 2. Is the url === "."? If so, it's a local git-relative path.
>>>>>>>>>> Already fully supported.
>>>>>>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new
>>>>>>>>>> plugin can be found at path.resolve(path_to_current_plugin,
>>>>>>>>>> dep.attrib.url); Though some path-separator tweaking is always
>>>>>>>>>>required.
>>>>>>>>>>
>>>>>>>>> I think this will be confusing. For case #3, you have the "url"
>>>>>> attribute that defines the path, and not the url. I would look at
>>>>>>this and
>>>>>> interpret it as a relative URL, and the URL is meant to tell you
>>>>>>where the
>>>>>> git repo is. It would be much clearer to call this "path" instead of
>>>>>>"url"
>>>>>> for #3 I think.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>>> (Re: paths, all paths in plugin.xml should be specified to use /
>>>>>>>>>> always, URLs and filesystem paths both. It's the tool's job to
>>>>>>>>>>properly
>>>>>>>>>> split and convert to Windows backslashes where appropriate. I'm
>>>>>>>>>>sure there
>>>>>>>>>> are a few places where we've gotten this wrong; Windows users
>>>>>>>>>>please file
>>>>>>>>>> bugs if you run into them. Mostly, though, I was careful to
>>>>>>>>>>split/join
>>>>>>>>>> explicitly on / or use path.foo functions appropriately.)
>>>>>>>>>>
>>>>>>>>>> Thoughts on that proposal?
>>>>>>>>>>
>>>>>>>>>> Braden
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny
>>>>>>>>>><mm...@chromium.org>wrote:
>>>>>>>>>>
>>>>>>>>>>> For now, yes, but we could extend that without breaking
>>>>>>>>>>>anything,
>>>>>>>>>>> no?
>>>>>>>>>>>  Right now url="../etc" would be invalid, so we could safely
>>>>>>>>>>>add
>>>>>>>>>>> support
>>>>>>>>>>> for urls with leading "..", and make that relative to current
>>>>>>>>>>> plugin.
>>>>>>>>>>>
>>>>>>>>>>> url="." would still do what it does today, but could likely be
>>>>>>>>>>> deprecated
>>>>>>>>>>> along with subdir and commit attributes (or at least document
>>>>>>>>>>>the
>>>>>>>>>>> limitation of that approach somewhere).
>>>>>>>>>>>
>>>>>>>>>>> Not sure about making the form url="./etc" be relative to URL
>>>>>>>>>>>root
>>>>>>>>>>> or
>>>>>>>>>>> current plugin, but I don't see why that form would ever be
>>>>>>>>>>>useful
>>>>>>>>>>> anyway.
>>>>>>>>>>>
>>>>>>>>>>> -Michal
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <
>>>>>>>>>>> agrieve@chromium.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> > Because for the hosted case, the URL points to where the repo
>>>>>>>>>>> is, not to
>>>>>>>>>>> > where the plugin is.
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <
>>>>>>>>>>> mmocny@chromium.org> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> >> If URL can be relative, why do we need a new path parameter?
>>>>>>>>>>>  All we
>>>>>>>>>>> >> would need is to treat leading ./ or ../ as relative to the
>>>>>>>>>>> plugin not
>>>>>>>>>>> >> root, which I think is fine.
>>>>>>>>>>> >>
>>>>>>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to
>>>>>>>>>>>make
>>>>>>>>>>> sure all
>>>>>>>>>>> >> the cases are handled.
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
>>>>>>>>>>> agrieve@chromium.org>wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >>> Agree the use-case is valid. Here's a variation on (1) that
>>>>>>>>>>>I
>>>>>>>>>>> think is
>>>>>>>>>>> >>> marginally nicer:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> url="." to be made optional, but default value is "."
>>>>>>>>>>> >>> subdir="" works only with git repos and is always relative
>>>>>>>>>>>to
>>>>>>>>>>> the root
>>>>>>>>>>> >>> of the repo.
>>>>>>>>>>> >>> path="" works with git repos or local paths and is relative
>>>>>>>>>>>to
>>>>>>>>>>> the
>>>>>>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or
>>>>>>>>>>> "subdir" if you
>>>>>>>>>>> >>> have "path".
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Support was just added for specifying commit and path
>>>>>>>>>>>within
>>>>>>>>>>> url. So, we
>>>>>>>>>>> >>> could actually just deprecate "subdir". and have "url" or
>>>>>>>>>>> "path"
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative
>>>>>>>>>>>to
>>>>>>>>>>> the
>>>>>>>>>>> >>> current plugin's git url.
>>>>>>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current
>>>>>>>>>>>URL
>>>>>>>>>>> >>> (cordova-labs style)
>>>>>>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on
>>>>>>>>>>>the
>>>>>>>>>>> current URL
>>>>>>>>>>> >>> plus a subdir within it.
>>>>>>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you
>>>>>>>>>>> just want to
>>>>>>>>>>> >>> set the path)
>>>>>>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the
>>>>>>>>>>>current
>>>>>>>>>>> plugin is
>>>>>>>>>>> >>> from git, then be careful not to go above the git root.
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <
>>>>>>>>>>> mmocny@chromium.org>wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>> Mulling this over a bit, I think I would like a solution
>>>>>>>>>>>for
>>>>>>>>>>> specifying
>>>>>>>>>>> >>>> dependancies that would work regardless of where/how the
>>>>>>>>>>> plugins are
>>>>>>>>>>> >>>> hosted, git or local.  If you had:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> BB_PLUGINS/
>>>>>>>>>>> >>>> - plug1/
>>>>>>>>>>> >>>> - plug2/
>>>>>>>>>>> >>>> ...
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> (and plug1 depends on plug2), then:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1
>>>>>>>>>>>..and..
>>>>>>>>>>>   cordova
>>>>>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> ..should both work without changing all of the dependency
>>>>>>>>>>> tags in plug1.
>>>>>>>>>>> >>>>  Actually, the plugin author should not have an explicit
>>>>>>>>>>>say
>>>>>>>>>>> in how a
>>>>>>>>>>> >>>> user
>>>>>>>>>>> >>>> manages these directories (except in the directory
>>>>>>>>>>> structure).  Note
>>>>>>>>>>> >>>> that
>>>>>>>>>>> >>>> this situation applies whenever a user clones your plugin
>>>>>>>>>>> repo to
>>>>>>>>>>> >>>> locally,
>>>>>>>>>>> >>>> or for the reverse direction, when ever they add your
>>>>>>>>>>>plugins
>>>>>>>>>>> into their
>>>>>>>>>>> >>>> teams' git repo.
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Right now, thats not possible, because when installing
>>>>>>>>>>>from
>>>>>>>>>>> local path
>>>>>>>>>>> >>>> with
>>>>>>>>>>> >>>> url="." there is no way to know which of the plugins
>>>>>>>>>>>parent
>>>>>>>>>>> directories
>>>>>>>>>>> >>>> to
>>>>>>>>>>> >>>> consider as the "root".  We could resolve this using
>>>>>>>>>>>several
>>>>>>>>>>> ways, among
>>>>>>>>>>> >>>> them:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path
>>>>>>>>>>> relative to this
>>>>>>>>>>> >>>> plugin" (note however, that I propose it also works when
>>>>>>>>>>> installing
>>>>>>>>>>> >>>> from a
>>>>>>>>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> (2) Support a new special file to "mark" the plugin root
>>>>>>>>>>>dir
>>>>>>>>>>> so we can
>>>>>>>>>>> >>>> walk
>>>>>>>>>>> >>>> the directory tree to find the valid target for url="."
>>>>>>>>>>>(ie,
>>>>>>>>>>> replace the
>>>>>>>>>>> >>>> requirement for a .git with a requirement for a
>>>>>>>>>>> .cordova_repo, which BB
>>>>>>>>>>> >>>> and
>>>>>>>>>>> >>>> others could place within their plugin bundle).
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> I like (1).
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> -Michal
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <
>>>>>>>>>>> mmocny@chromium.org>
>>>>>>>>>>> >>>> wrote:
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> > Sounds reasonable to me.
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2)
>>>>>>>>>>>shouldn't
>>>>>>>>>>> do what
>>>>>>>>>>> >>>> you
>>>>>>>>>>> >>>> > request when the url for the original plugin was a local
>>>>>>>>>>> path?  Maybe
>>>>>>>>>>> >>>> just
>>>>>>>>>>> >>>> > a bug?
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> > -Michal
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>>>>>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> >> We were working on a redistribution of Cordova that
>>>>>>>>>>> included some
>>>>>>>>>>> >>>> plugins
>>>>>>>>>>> >>>> >> and ran into a use-case not covered by the current
>>>>>>>>>>>plugin
>>>>>>>>>>> spec.[1]
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >> Currently there are two ways to specify a dependency
>>>>>>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which
>>>>>>>>>>> plugman will
>>>>>>>>>>> >>>> use
>>>>>>>>>>> >>>> >> to clone down a repo and install
>>>>>>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a
>>>>>>>>>>> subdir relative
>>>>>>>>>>> >>>> to
>>>>>>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse
>>>>>>>>>>>to
>>>>>>>>>>> find the
>>>>>>>>>>> >>>> root and
>>>>>>>>>>> >>>> >> install from there.
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >> I would like to propose a third way which would be
>>>>>>>>>>> relative to the
>>>>>>>>>>> >>>> >> current install and not use git at all
>>>>>>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir
>>>>>>>>>>> relative to the
>>>>>>>>>>> >>>> >> current plugin.xml.
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >> This would allow us to distribute a version of cordova
>>>>>>>>>>> with plugins
>>>>>>>>>>> >>>> to
>>>>>>>>>>> >>>> >> anyone without an unnecessary requirement on git
>>>>>>>>>>> (considering the
>>>>>>>>>>> >>>> plugins
>>>>>>>>>>> >>>> >> are fully installed)
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >> 1.
>>>>>>>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> 
>>>>>>>>>>>----------------------------------------------------------------
>>>>>>>>>>>-
>>>>>>>>>>>----
>>>>>>>>>>> >>>> >> This transmission (including any attachments) may
>>>>>>>>>>>contain
>>>>>>>>>>> >>>> confidential
>>>>>>>>>>> >>>> >> information, privileged material (including material
>>>>>>>>>>> protected by the
>>>>>>>>>>> >>>> >> solicitor-client or other applicable privileges), or
>>>>>>>>>>> constitute
>>>>>>>>>>> >>>> non-public
>>>>>>>>>>> >>>> >> information. Any use of this information by anyone
>>>>>>>>>>>other
>>>>>>>>>>> than the
>>>>>>>>>>> >>>> intended
>>>>>>>>>>> >>>> >> recipient is prohibited. If you have received this
>>>>>>>>>>> transmission in
>>>>>>>>>>> >>>> error,
>>>>>>>>>>> >>>> >> please immediately reply to the sender and delete this
>>>>>>>>>>> information
>>>>>>>>>>> >>>> from
>>>>>>>>>>> >>>> >> your system. Use, dissemination, distribution, or
>>>>>>>>>>> reproduction of
>>>>>>>>>>> >>>> this
>>>>>>>>>>> >>>> >> transmission by unintended recipients is not authorized
>>>>>>>>>>> and may be
>>>>>>>>>>> >>>> unlawful.
>>>>>>>>>>> >>>> >>
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>> >
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
>---------------------------------------------------------------------
>This transmission (including any attachments) may contain confidential
>information, privileged material (including material protected by the
>solicitor-client or other applicable privileges), or constitute
>non-public information. Any use of this information by anyone other than
>the intended recipient is prohibited. If you have received this
>transmission in error, please immediately reply to the sender and delete
>this information from your system. Use, dissemination, distribution, or
>reproduction of this transmission by unintended recipients is not
>authorized and may be unlawful.


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: Non-Git Plugin Dependencies

Posted by Jeffrey Heifetz <jh...@blackberry.com>.
While I believe we could be able to specify everything with a single
parameter, I don't follow what problem we're trying to solve by doing so.

If I understand everything correctly we're comparing the following;
   <dependency src=url#branch:subdir />
   <dependency url=url commit=branch subdir=subdir />

While both seem reasonable and I do like the first, this seems unnecessary.

On 13-09-04 3:18 PM, "Braden Shepherdson" <br...@chromium.org> wrote:

>Not quite, since the checked-out directories generally don't have the
>".git" suffix; you'd have to override git's normal naming behavior when
>cloning these.
>
>I think that's quite a bit of delicate magic we don't need. I think src
>might be a better name, if we wanted to go with a single parameter.
>
>If we want to go with two, I like url and path. Supplying both and
>choosing
>based on where the parent plugin was fetched from, that would probably
>work.
>
>I think src="" and my three use cases above works. Thoughts?
>
>Braden
>
>
>On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <ag...@chromium.org>
>wrote:
>
>> Here's another use-case:
>> - You have a github account
>> - You have one plugin per repo
>> - URLs look like: https://github.com/MobileChromeApps/AppBundle.git
>> - You want AppBundle to depend on
>> https://github.com/MobileChromeApps/zip.git
>> - You want this to work when you've got your plugins checked out for
>>local
>> dev:
>> plugins/AppBundle.git
>> plugins/zip.git
>>
>> You try <dependency src="zip.git" />
>>
>> If we treated this as a relative URL, then it would actually work in
>>both
>> cases (online or checked out). If we treat non-absolute-urls as subdirs,
>> then things don't work out for this use-case. If we use path= for
>>subdirs
>> and url= for repo URLs, then both use-cases work out.
>>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mm...@chromium.org>
>>wrote:
>>
>>> I'm not convinced that all use cases cannot be handled with a single
>>> attribute.  Maybe url / path are the wrong names, maybe a single
>>>src="".
>>>
>>>
>>> On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson
>>><br...@chromium.org>wrote:
>>>
>>>> Sure, I can work with path="" instead. What happens if (when) a user
>>>> supplies both?
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve
>>>><ag...@chromium.org>wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <
>>>>> braden@chromium.org> wrote:
>>>>>
>>>>>> I believe the current logic is "a plugin with this ID is already
>>>>>> installed, so stop". That interacts badly with different versions.
>>>>>>
>>>>>> Braden
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny
>>>>>><mm...@chromium.org>wrote:
>>>>>>
>>>>>>> .. but either way if we add support for filesystem-relative paths
>>>>>>>and
>>>>>>> they work when fetching the original plugin either from git or
>>>>>>>locally,
>>>>>>> then we are done.
>>>>>>>
>>>>>>> As an aside, when a plugin lists its dependency as explicitly from
>>>>>>>a
>>>>>>> git url, can the user somehow override that to install from a
>>>>>>>local copy?
>>>>>>>  Perhaps if they manually install the dependant first, then we
>>>>>>>won't go
>>>>>>> fetch from git needlessly?  How does that interact with different
>>>>>>>versions
>>>>>>> of the plugin?
>>>>>>>
>>>>>>> -Michal
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny
>>>>>>><mm...@chromium.org>wrote:
>>>>>>>
>>>>>>>> Jeffrey's point at the start of this thread is that he isn't
>>>>>>>>using a
>>>>>>>> git repo locally, so there is no .git folder to find.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
>>>>>>>> braden@chromium.org> wrote:
>>>>>>>>
>>>>>>>>> I like where this is generally going, but I want to correct one
>>>>>>>>> mistake Michal made. There /is/ a way to know which directory
>>>>>>>>>above a
>>>>>>>>> plugin is the root. The code uses git to find the .git
>>>>>>>>>directory, which is
>>>>>>>>> taken to be the root from which the subdir is relative. That
>>>>>>>>>means that in
>>>>>>>>> the case of url="." and url="https://github.com/..." the subdir
>>>>>>>>> has the same meaning: relative to the git root.
>>>>>>>>>
>>>>>>>>> I like the path="" option. I agree that subdir and ref could be
>>>>>>>>> dropped, since they can be specified as part of the URL. On the
>>>>>>>>>other hand,
>>>>>>>>> there's no harm in keeping them around for compatibility.
>>>>>>>>>
>>>>>>>>> I suggest:
>>>>>>>>>
>>>>>>>>> 1. Remote git, all in URL: url="
>>>>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>>>>>>  2. Remote git, separate parameters: url="
>>>>>>>>> https://github.com/foo/bar.git" subdir="sub/dir" ref="somebranch"
>>>>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir"
>>>>>>>>> ref="somebranch"      (we can probably support all-in-URL here
>>>>>>>>>too)
>>>>>>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no
>>>>>>>>> all-in-URL here; there's no need for the other parameters in
>>>>>>>>>this case)
>>>>>>>>>
>>>>>>>>> The last can be differentiated from the others easily enough, the
>>>>>>>>> logic is:
>>>>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a
>>>>>>>>> remote git. This is already supported fully.
>>>>>>>>> 2. Is the url === "."? If so, it's a local git-relative path.
>>>>>>>>> Already fully supported.
>>>>>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new
>>>>>>>>> plugin can be found at path.resolve(path_to_current_plugin,
>>>>>>>>> dep.attrib.url); Though some path-separator tweaking is always
>>>>>>>>>required.
>>>>>>>>>
>>>>>>>> I think this will be confusing. For case #3, you have the "url"
>>>>> attribute that defines the path, and not the url. I would look at
>>>>>this and
>>>>> interpret it as a relative URL, and the URL is meant to tell you
>>>>>where the
>>>>> git repo is. It would be much clearer to call this "path" instead of
>>>>>"url"
>>>>> for #3 I think.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>>> (Re: paths, all paths in plugin.xml should be specified to use /
>>>>>>>>> always, URLs and filesystem paths both. It's the tool's job to
>>>>>>>>>properly
>>>>>>>>> split and convert to Windows backslashes where appropriate. I'm
>>>>>>>>>sure there
>>>>>>>>> are a few places where we've gotten this wrong; Windows users
>>>>>>>>>please file
>>>>>>>>> bugs if you run into them. Mostly, though, I was careful to
>>>>>>>>>split/join
>>>>>>>>> explicitly on / or use path.foo functions appropriately.)
>>>>>>>>>
>>>>>>>>> Thoughts on that proposal?
>>>>>>>>>
>>>>>>>>> Braden
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny
>>>>>>>>><mm...@chromium.org>wrote:
>>>>>>>>>
>>>>>>>>>> For now, yes, but we could extend that without breaking
>>>>>>>>>>anything,
>>>>>>>>>> no?
>>>>>>>>>>  Right now url="../etc" would be invalid, so we could safely add
>>>>>>>>>> support
>>>>>>>>>> for urls with leading "..", and make that relative to current
>>>>>>>>>> plugin.
>>>>>>>>>>
>>>>>>>>>> url="." would still do what it does today, but could likely be
>>>>>>>>>> deprecated
>>>>>>>>>> along with subdir and commit attributes (or at least document
>>>>>>>>>>the
>>>>>>>>>> limitation of that approach somewhere).
>>>>>>>>>>
>>>>>>>>>> Not sure about making the form url="./etc" be relative to URL
>>>>>>>>>>root
>>>>>>>>>> or
>>>>>>>>>> current plugin, but I don't see why that form would ever be
>>>>>>>>>>useful
>>>>>>>>>> anyway.
>>>>>>>>>>
>>>>>>>>>> -Michal
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <
>>>>>>>>>> agrieve@chromium.org> wrote:
>>>>>>>>>>
>>>>>>>>>> > Because for the hosted case, the URL points to where the repo
>>>>>>>>>> is, not to
>>>>>>>>>> > where the plugin is.
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <
>>>>>>>>>> mmocny@chromium.org> wrote:
>>>>>>>>>> >
>>>>>>>>>> >> If URL can be relative, why do we need a new path parameter?
>>>>>>>>>>  All we
>>>>>>>>>> >> would need is to treat leading ./ or ../ as relative to the
>>>>>>>>>> plugin not
>>>>>>>>>> >> root, which I think is fine.
>>>>>>>>>> >>
>>>>>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to
>>>>>>>>>>make
>>>>>>>>>> sure all
>>>>>>>>>> >> the cases are handled.
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
>>>>>>>>>> agrieve@chromium.org>wrote:
>>>>>>>>>> >>
>>>>>>>>>> >>> Agree the use-case is valid. Here's a variation on (1) that
>>>>>>>>>>I
>>>>>>>>>> think is
>>>>>>>>>> >>> marginally nicer:
>>>>>>>>>> >>>
>>>>>>>>>> >>> url="." to be made optional, but default value is "."
>>>>>>>>>> >>> subdir="" works only with git repos and is always relative
>>>>>>>>>>to
>>>>>>>>>> the root
>>>>>>>>>> >>> of the repo.
>>>>>>>>>> >>> path="" works with git repos or local paths and is relative
>>>>>>>>>>to
>>>>>>>>>> the
>>>>>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or
>>>>>>>>>> "subdir" if you
>>>>>>>>>> >>> have "path".
>>>>>>>>>> >>>
>>>>>>>>>> >>> Support was just added for specifying commit and path within
>>>>>>>>>> url. So, we
>>>>>>>>>> >>> could actually just deprecate "subdir". and have "url" or
>>>>>>>>>> "path"
>>>>>>>>>> >>>
>>>>>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative
>>>>>>>>>>to
>>>>>>>>>> the
>>>>>>>>>> >>> current plugin's git url.
>>>>>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current
>>>>>>>>>>URL
>>>>>>>>>> >>> (cordova-labs style)
>>>>>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the
>>>>>>>>>> current URL
>>>>>>>>>> >>> plus a subdir within it.
>>>>>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you
>>>>>>>>>> just want to
>>>>>>>>>> >>> set the path)
>>>>>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the
>>>>>>>>>>current
>>>>>>>>>> plugin is
>>>>>>>>>> >>> from git, then be careful not to go above the git root.
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <
>>>>>>>>>> mmocny@chromium.org>wrote:
>>>>>>>>>> >>>
>>>>>>>>>> >>>> Mulling this over a bit, I think I would like a solution
>>>>>>>>>>for
>>>>>>>>>> specifying
>>>>>>>>>> >>>> dependancies that would work regardless of where/how the
>>>>>>>>>> plugins are
>>>>>>>>>> >>>> hosted, git or local.  If you had:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> BB_PLUGINS/
>>>>>>>>>> >>>> - plug1/
>>>>>>>>>> >>>> - plug2/
>>>>>>>>>> >>>> ...
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> (and plug1 depends on plug2), then:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1
>>>>>>>>>>..and..
>>>>>>>>>>   cordova
>>>>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> ..should both work without changing all of the dependency
>>>>>>>>>> tags in plug1.
>>>>>>>>>> >>>>  Actually, the plugin author should not have an explicit
>>>>>>>>>>say
>>>>>>>>>> in how a
>>>>>>>>>> >>>> user
>>>>>>>>>> >>>> manages these directories (except in the directory
>>>>>>>>>> structure).  Note
>>>>>>>>>> >>>> that
>>>>>>>>>> >>>> this situation applies whenever a user clones your plugin
>>>>>>>>>> repo to
>>>>>>>>>> >>>> locally,
>>>>>>>>>> >>>> or for the reverse direction, when ever they add your
>>>>>>>>>>plugins
>>>>>>>>>> into their
>>>>>>>>>> >>>> teams' git repo.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Right now, thats not possible, because when installing from
>>>>>>>>>> local path
>>>>>>>>>> >>>> with
>>>>>>>>>> >>>> url="." there is no way to know which of the plugins parent
>>>>>>>>>> directories
>>>>>>>>>> >>>> to
>>>>>>>>>> >>>> consider as the "root".  We could resolve this using
>>>>>>>>>>several
>>>>>>>>>> ways, among
>>>>>>>>>> >>>> them:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path
>>>>>>>>>> relative to this
>>>>>>>>>> >>>> plugin" (note however, that I propose it also works when
>>>>>>>>>> installing
>>>>>>>>>> >>>> from a
>>>>>>>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> (2) Support a new special file to "mark" the plugin root
>>>>>>>>>>dir
>>>>>>>>>> so we can
>>>>>>>>>> >>>> walk
>>>>>>>>>> >>>> the directory tree to find the valid target for url="."
>>>>>>>>>>(ie,
>>>>>>>>>> replace the
>>>>>>>>>> >>>> requirement for a .git with a requirement for a
>>>>>>>>>> .cordova_repo, which BB
>>>>>>>>>> >>>> and
>>>>>>>>>> >>>> others could place within their plugin bundle).
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> I like (1).
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> -Michal
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <
>>>>>>>>>> mmocny@chromium.org>
>>>>>>>>>> >>>> wrote:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> > Sounds reasonable to me.
>>>>>>>>>> >>>> >
>>>>>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2)
>>>>>>>>>>shouldn't
>>>>>>>>>> do what
>>>>>>>>>> >>>> you
>>>>>>>>>> >>>> > request when the url for the original plugin was a local
>>>>>>>>>> path?  Maybe
>>>>>>>>>> >>>> just
>>>>>>>>>> >>>> > a bug?
>>>>>>>>>> >>>> >
>>>>>>>>>> >>>> > -Michal
>>>>>>>>>> >>>> >
>>>>>>>>>> >>>> >
>>>>>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>>>>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>>>>>>> >>>> >
>>>>>>>>>> >>>> >> We were working on a redistribution of Cordova that
>>>>>>>>>> included some
>>>>>>>>>> >>>> plugins
>>>>>>>>>> >>>> >> and ran into a use-case not covered by the current
>>>>>>>>>>plugin
>>>>>>>>>> spec.[1]
>>>>>>>>>> >>>> >>
>>>>>>>>>> >>>> >> Currently there are two ways to specify a dependency
>>>>>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which
>>>>>>>>>> plugman will
>>>>>>>>>> >>>> use
>>>>>>>>>> >>>> >> to clone down a repo and install
>>>>>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a
>>>>>>>>>> subdir relative
>>>>>>>>>> >>>> to
>>>>>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse to
>>>>>>>>>> find the
>>>>>>>>>> >>>> root and
>>>>>>>>>> >>>> >> install from there.
>>>>>>>>>> >>>> >>
>>>>>>>>>> >>>> >> I would like to propose a third way which would be
>>>>>>>>>> relative to the
>>>>>>>>>> >>>> >> current install and not use git at all
>>>>>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir
>>>>>>>>>> relative to the
>>>>>>>>>> >>>> >> current plugin.xml.
>>>>>>>>>> >>>> >>
>>>>>>>>>> >>>> >> This would allow us to distribute a version of cordova
>>>>>>>>>> with plugins
>>>>>>>>>> >>>> to
>>>>>>>>>> >>>> >> anyone without an unnecessary requirement on git
>>>>>>>>>> (considering the
>>>>>>>>>> >>>> plugins
>>>>>>>>>> >>>> >> are fully installed)
>>>>>>>>>> >>>> >>
>>>>>>>>>> >>>> >>
>>>>>>>>>> >>>> >>
>>>>>>>>>> >>>> >> 1.
>>>>>>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>>>>>>> >>>> >>
>>>>>>>>>> >>>> >>
>>>>>>>>>> 
>>>>>>>>>>-----------------------------------------------------------------
>>>>>>>>>>----
>>>>>>>>>> >>>> >> This transmission (including any attachments) may
>>>>>>>>>>contain
>>>>>>>>>> >>>> confidential
>>>>>>>>>> >>>> >> information, privileged material (including material
>>>>>>>>>> protected by the
>>>>>>>>>> >>>> >> solicitor-client or other applicable privileges), or
>>>>>>>>>> constitute
>>>>>>>>>> >>>> non-public
>>>>>>>>>> >>>> >> information. Any use of this information by anyone other
>>>>>>>>>> than the
>>>>>>>>>> >>>> intended
>>>>>>>>>> >>>> >> recipient is prohibited. If you have received this
>>>>>>>>>> transmission in
>>>>>>>>>> >>>> error,
>>>>>>>>>> >>>> >> please immediately reply to the sender and delete this
>>>>>>>>>> information
>>>>>>>>>> >>>> from
>>>>>>>>>> >>>> >> your system. Use, dissemination, distribution, or
>>>>>>>>>> reproduction of
>>>>>>>>>> >>>> this
>>>>>>>>>> >>>> >> transmission by unintended recipients is not authorized
>>>>>>>>>> and may be
>>>>>>>>>> >>>> unlawful.
>>>>>>>>>> >>>> >>
>>>>>>>>>> >>>> >
>>>>>>>>>> >>>> >
>>>>>>>>>> >>>>
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: Non-Git Plugin Dependencies

Posted by Braden Shepherdson <br...@chromium.org>.
Not quite, since the checked-out directories generally don't have the
".git" suffix; you'd have to override git's normal naming behavior when
cloning these.

I think that's quite a bit of delicate magic we don't need. I think src
might be a better name, if we wanted to go with a single parameter.

If we want to go with two, I like url and path. Supplying both and choosing
based on where the parent plugin was fetched from, that would probably work.

I think src="" and my three use cases above works. Thoughts?

Braden


On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Here's another use-case:
> - You have a github account
> - You have one plugin per repo
> - URLs look like: https://github.com/MobileChromeApps/AppBundle.git
> - You want AppBundle to depend on
> https://github.com/MobileChromeApps/zip.git
> - You want this to work when you've got your plugins checked out for local
> dev:
> plugins/AppBundle.git
> plugins/zip.git
>
> You try <dependency src="zip.git" />
>
> If we treated this as a relative URL, then it would actually work in both
> cases (online or checked out). If we treat non-absolute-urls as subdirs,
> then things don't work out for this use-case. If we use path= for subdirs
> and url= for repo URLs, then both use-cases work out.
>
>
>
>
> On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>> I'm not convinced that all use cases cannot be handled with a single
>> attribute.  Maybe url / path are the wrong names, maybe a single src="".
>>
>>
>> On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson <br...@chromium.org>wrote:
>>
>>> Sure, I can work with path="" instead. What happens if (when) a user
>>> supplies both?
>>>
>>>
>>> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <
>>>> braden@chromium.org> wrote:
>>>>
>>>>> I believe the current logic is "a plugin with this ID is already
>>>>> installed, so stop". That interacts badly with different versions.
>>>>>
>>>>> Braden
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>>
>>>>>> .. but either way if we add support for filesystem-relative paths and
>>>>>> they work when fetching the original plugin either from git or locally,
>>>>>> then we are done.
>>>>>>
>>>>>> As an aside, when a plugin lists its dependency as explicitly from a
>>>>>> git url, can the user somehow override that to install from a local copy?
>>>>>>  Perhaps if they manually install the dependant first, then we won't go
>>>>>> fetch from git needlessly?  How does that interact with different versions
>>>>>> of the plugin?
>>>>>>
>>>>>> -Michal
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>>>
>>>>>>> Jeffrey's point at the start of this thread is that he isn't using a
>>>>>>> git repo locally, so there is no .git folder to find.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
>>>>>>> braden@chromium.org> wrote:
>>>>>>>
>>>>>>>> I like where this is generally going, but I want to correct one
>>>>>>>> mistake Michal made. There /is/ a way to know which directory above a
>>>>>>>> plugin is the root. The code uses git to find the .git directory, which is
>>>>>>>> taken to be the root from which the subdir is relative. That means that in
>>>>>>>> the case of url="." and url="https://github.com/..." the subdir
>>>>>>>> has the same meaning: relative to the git root.
>>>>>>>>
>>>>>>>> I like the path="" option. I agree that subdir and ref could be
>>>>>>>> dropped, since they can be specified as part of the URL. On the other hand,
>>>>>>>> there's no harm in keeping them around for compatibility.
>>>>>>>>
>>>>>>>> I suggest:
>>>>>>>>
>>>>>>>> 1. Remote git, all in URL: url="
>>>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>>>>>  2. Remote git, separate parameters: url="
>>>>>>>> https://github.com/foo/bar.git" subdir="sub/dir" ref="somebranch"
>>>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir"
>>>>>>>> ref="somebranch"      (we can probably support all-in-URL here too)
>>>>>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no
>>>>>>>> all-in-URL here; there's no need for the other parameters in this case)
>>>>>>>>
>>>>>>>> The last can be differentiated from the others easily enough, the
>>>>>>>> logic is:
>>>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a
>>>>>>>> remote git. This is already supported fully.
>>>>>>>> 2. Is the url === "."? If so, it's a local git-relative path.
>>>>>>>> Already fully supported.
>>>>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new
>>>>>>>> plugin can be found at path.resolve(path_to_current_plugin,
>>>>>>>> dep.attrib.url); Though some path-separator tweaking is always required.
>>>>>>>>
>>>>>>> I think this will be confusing. For case #3, you have the "url"
>>>> attribute that defines the path, and not the url. I would look at this and
>>>> interpret it as a relative URL, and the URL is meant to tell you where the
>>>> git repo is. It would be much clearer to call this "path" instead of "url"
>>>> for #3 I think.
>>>>
>>>>
>>>>
>>>>>
>>>>>>>> (Re: paths, all paths in plugin.xml should be specified to use /
>>>>>>>> always, URLs and filesystem paths both. It's the tool's job to properly
>>>>>>>> split and convert to Windows backslashes where appropriate. I'm sure there
>>>>>>>> are a few places where we've gotten this wrong; Windows users please file
>>>>>>>> bugs if you run into them. Mostly, though, I was careful to split/join
>>>>>>>> explicitly on / or use path.foo functions appropriately.)
>>>>>>>>
>>>>>>>> Thoughts on that proposal?
>>>>>>>>
>>>>>>>> Braden
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>>>>>
>>>>>>>>> For now, yes, but we could extend that without breaking anything,
>>>>>>>>> no?
>>>>>>>>>  Right now url="../etc" would be invalid, so we could safely add
>>>>>>>>> support
>>>>>>>>> for urls with leading "..", and make that relative to current
>>>>>>>>> plugin.
>>>>>>>>>
>>>>>>>>> url="." would still do what it does today, but could likely be
>>>>>>>>> deprecated
>>>>>>>>> along with subdir and commit attributes (or at least document the
>>>>>>>>> limitation of that approach somewhere).
>>>>>>>>>
>>>>>>>>> Not sure about making the form url="./etc" be relative to URL root
>>>>>>>>> or
>>>>>>>>> current plugin, but I don't see why that form would ever be useful
>>>>>>>>> anyway.
>>>>>>>>>
>>>>>>>>> -Michal
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <
>>>>>>>>> agrieve@chromium.org> wrote:
>>>>>>>>>
>>>>>>>>> > Because for the hosted case, the URL points to where the repo
>>>>>>>>> is, not to
>>>>>>>>> > where the plugin is.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <
>>>>>>>>> mmocny@chromium.org> wrote:
>>>>>>>>> >
>>>>>>>>> >> If URL can be relative, why do we need a new path parameter?
>>>>>>>>>  All we
>>>>>>>>> >> would need is to treat leading ./ or ../ as relative to the
>>>>>>>>> plugin not
>>>>>>>>> >> root, which I think is fine.
>>>>>>>>> >>
>>>>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to make
>>>>>>>>> sure all
>>>>>>>>> >> the cases are handled.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
>>>>>>>>> agrieve@chromium.org>wrote:
>>>>>>>>> >>
>>>>>>>>> >>> Agree the use-case is valid. Here's a variation on (1) that I
>>>>>>>>> think is
>>>>>>>>> >>> marginally nicer:
>>>>>>>>> >>>
>>>>>>>>> >>> url="." to be made optional, but default value is "."
>>>>>>>>> >>> subdir="" works only with git repos and is always relative to
>>>>>>>>> the root
>>>>>>>>> >>> of the repo.
>>>>>>>>> >>> path="" works with git repos or local paths and is relative to
>>>>>>>>> the
>>>>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or
>>>>>>>>> "subdir" if you
>>>>>>>>> >>> have "path".
>>>>>>>>> >>>
>>>>>>>>> >>> Support was just added for specifying commit and path within
>>>>>>>>> url. So, we
>>>>>>>>> >>> could actually just deprecate "subdir". and have "url" or
>>>>>>>>> "path"
>>>>>>>>> >>>
>>>>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative to
>>>>>>>>> the
>>>>>>>>> >>> current plugin's git url.
>>>>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current URL
>>>>>>>>> >>> (cordova-labs style)
>>>>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the
>>>>>>>>> current URL
>>>>>>>>> >>> plus a subdir within it.
>>>>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you
>>>>>>>>> just want to
>>>>>>>>> >>> set the path)
>>>>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the current
>>>>>>>>> plugin is
>>>>>>>>> >>> from git, then be careful not to go above the git root.
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <
>>>>>>>>> mmocny@chromium.org>wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>> Mulling this over a bit, I think I would like a solution for
>>>>>>>>> specifying
>>>>>>>>> >>>> dependancies that would work regardless of where/how the
>>>>>>>>> plugins are
>>>>>>>>> >>>> hosted, git or local.  If you had:
>>>>>>>>> >>>>
>>>>>>>>> >>>> BB_PLUGINS/
>>>>>>>>> >>>> - plug1/
>>>>>>>>> >>>> - plug2/
>>>>>>>>> >>>> ...
>>>>>>>>> >>>>
>>>>>>>>> >>>> (and plug1 depends on plug2), then:
>>>>>>>>> >>>>
>>>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..
>>>>>>>>>   cordova
>>>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>>>>>> >>>>
>>>>>>>>> >>>> ..should both work without changing all of the dependency
>>>>>>>>> tags in plug1.
>>>>>>>>> >>>>  Actually, the plugin author should not have an explicit say
>>>>>>>>> in how a
>>>>>>>>> >>>> user
>>>>>>>>> >>>> manages these directories (except in the directory
>>>>>>>>> structure).  Note
>>>>>>>>> >>>> that
>>>>>>>>> >>>> this situation applies whenever a user clones your plugin
>>>>>>>>> repo to
>>>>>>>>> >>>> locally,
>>>>>>>>> >>>> or for the reverse direction, when ever they add your plugins
>>>>>>>>> into their
>>>>>>>>> >>>> teams' git repo.
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> Right now, thats not possible, because when installing from
>>>>>>>>> local path
>>>>>>>>> >>>> with
>>>>>>>>> >>>> url="." there is no way to know which of the plugins parent
>>>>>>>>> directories
>>>>>>>>> >>>> to
>>>>>>>>> >>>> consider as the "root".  We could resolve this using several
>>>>>>>>> ways, among
>>>>>>>>> >>>> them:
>>>>>>>>> >>>>
>>>>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path
>>>>>>>>> relative to this
>>>>>>>>> >>>> plugin" (note however, that I propose it also works when
>>>>>>>>> installing
>>>>>>>>> >>>> from a
>>>>>>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>>>>>>> >>>>
>>>>>>>>> >>>> (2) Support a new special file to "mark" the plugin root dir
>>>>>>>>> so we can
>>>>>>>>> >>>> walk
>>>>>>>>> >>>> the directory tree to find the valid target for url="." (ie,
>>>>>>>>> replace the
>>>>>>>>> >>>> requirement for a .git with a requirement for a
>>>>>>>>> .cordova_repo, which BB
>>>>>>>>> >>>> and
>>>>>>>>> >>>> others could place within their plugin bundle).
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> I like (1).
>>>>>>>>> >>>>
>>>>>>>>> >>>> -Michal
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <
>>>>>>>>> mmocny@chromium.org>
>>>>>>>>> >>>> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> > Sounds reasonable to me.
>>>>>>>>> >>>> >
>>>>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't
>>>>>>>>> do what
>>>>>>>>> >>>> you
>>>>>>>>> >>>> > request when the url for the original plugin was a local
>>>>>>>>> path?  Maybe
>>>>>>>>> >>>> just
>>>>>>>>> >>>> > a bug?
>>>>>>>>> >>>> >
>>>>>>>>> >>>> > -Michal
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>>>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >> We were working on a redistribution of Cordova that
>>>>>>>>> included some
>>>>>>>>> >>>> plugins
>>>>>>>>> >>>> >> and ran into a use-case not covered by the current plugin
>>>>>>>>> spec.[1]
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >> Currently there are two ways to specify a dependency
>>>>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which
>>>>>>>>> plugman will
>>>>>>>>> >>>> use
>>>>>>>>> >>>> >> to clone down a repo and install
>>>>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a
>>>>>>>>> subdir relative
>>>>>>>>> >>>> to
>>>>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse to
>>>>>>>>> find the
>>>>>>>>> >>>> root and
>>>>>>>>> >>>> >> install from there.
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >> I would like to propose a third way which would be
>>>>>>>>> relative to the
>>>>>>>>> >>>> >> current install and not use git at all
>>>>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir
>>>>>>>>> relative to the
>>>>>>>>> >>>> >> current plugin.xml.
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >> This would allow us to distribute a version of cordova
>>>>>>>>> with plugins
>>>>>>>>> >>>> to
>>>>>>>>> >>>> >> anyone without an unnecessary requirement on git
>>>>>>>>> (considering the
>>>>>>>>> >>>> plugins
>>>>>>>>> >>>> >> are fully installed)
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >> 1.
>>>>>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> >>>> >> This transmission (including any attachments) may contain
>>>>>>>>> >>>> confidential
>>>>>>>>> >>>> >> information, privileged material (including material
>>>>>>>>> protected by the
>>>>>>>>> >>>> >> solicitor-client or other applicable privileges), or
>>>>>>>>> constitute
>>>>>>>>> >>>> non-public
>>>>>>>>> >>>> >> information. Any use of this information by anyone other
>>>>>>>>> than the
>>>>>>>>> >>>> intended
>>>>>>>>> >>>> >> recipient is prohibited. If you have received this
>>>>>>>>> transmission in
>>>>>>>>> >>>> error,
>>>>>>>>> >>>> >> please immediately reply to the sender and delete this
>>>>>>>>> information
>>>>>>>>> >>>> from
>>>>>>>>> >>>> >> your system. Use, dissemination, distribution, or
>>>>>>>>> reproduction of
>>>>>>>>> >>>> this
>>>>>>>>> >>>> >> transmission by unintended recipients is not authorized
>>>>>>>>> and may be
>>>>>>>>> >>>> unlawful.
>>>>>>>>> >>>> >>
>>>>>>>>> >>>> >
>>>>>>>>> >>>> >
>>>>>>>>> >>>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Andrew Grieve <ag...@chromium.org>.
Here's another use-case:
- You have a github account
- You have one plugin per repo
- URLs look like: https://github.com/MobileChromeApps/AppBundle.git
- You want AppBundle to depend on
https://github.com/MobileChromeApps/zip.git
- You want this to work when you've got your plugins checked out for local
dev:
plugins/AppBundle.git
plugins/zip.git

You try <dependency src="zip.git" />

If we treated this as a relative URL, then it would actually work in both
cases (online or checked out). If we treat non-absolute-urls as subdirs,
then things don't work out for this use-case. If we use path= for subdirs
and url= for repo URLs, then both use-cases work out.




On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mm...@chromium.org> wrote:

> I'm not convinced that all use cases cannot be handled with a single
> attribute.  Maybe url / path are the wrong names, maybe a single src="".
>
>
> On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> Sure, I can work with path="" instead. What happens if (when) a user
>> supplies both?
>>
>>
>> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>
>>>
>>>
>>>
>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <braden@chromium.org
>>> > wrote:
>>>
>>>> I believe the current logic is "a plugin with this ID is already
>>>> installed, so stop". That interacts badly with different versions.
>>>>
>>>> Braden
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>
>>>>> .. but either way if we add support for filesystem-relative paths and
>>>>> they work when fetching the original plugin either from git or locally,
>>>>> then we are done.
>>>>>
>>>>> As an aside, when a plugin lists its dependency as explicitly from a
>>>>> git url, can the user somehow override that to install from a local copy?
>>>>>  Perhaps if they manually install the dependant first, then we won't go
>>>>> fetch from git needlessly?  How does that interact with different versions
>>>>> of the plugin?
>>>>>
>>>>> -Michal
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>>
>>>>>> Jeffrey's point at the start of this thread is that he isn't using a
>>>>>> git repo locally, so there is no .git folder to find.
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
>>>>>> braden@chromium.org> wrote:
>>>>>>
>>>>>>> I like where this is generally going, but I want to correct one
>>>>>>> mistake Michal made. There /is/ a way to know which directory above a
>>>>>>> plugin is the root. The code uses git to find the .git directory, which is
>>>>>>> taken to be the root from which the subdir is relative. That means that in
>>>>>>> the case of url="." and url="https://github.com/..." the subdir has
>>>>>>> the same meaning: relative to the git root.
>>>>>>>
>>>>>>> I like the path="" option. I agree that subdir and ref could be
>>>>>>> dropped, since they can be specified as part of the URL. On the other hand,
>>>>>>> there's no harm in keeping them around for compatibility.
>>>>>>>
>>>>>>> I suggest:
>>>>>>>
>>>>>>> 1. Remote git, all in URL: url="
>>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>>>>  2. Remote git, separate parameters: url="
>>>>>>> https://github.com/foo/bar.git" subdir="sub/dir" ref="somebranch"
>>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir"
>>>>>>> ref="somebranch"      (we can probably support all-in-URL here too)
>>>>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no
>>>>>>> all-in-URL here; there's no need for the other parameters in this case)
>>>>>>>
>>>>>>> The last can be differentiated from the others easily enough, the
>>>>>>> logic is:
>>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a remote
>>>>>>> git. This is already supported fully.
>>>>>>> 2. Is the url === "."? If so, it's a local git-relative path.
>>>>>>> Already fully supported.
>>>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new plugin
>>>>>>> can be found at path.resolve(path_to_current_plugin, dep.attrib.url);
>>>>>>> Though some path-separator tweaking is always required.
>>>>>>>
>>>>>> I think this will be confusing. For case #3, you have the "url"
>>> attribute that defines the path, and not the url. I would look at this and
>>> interpret it as a relative URL, and the URL is meant to tell you where the
>>> git repo is. It would be much clearer to call this "path" instead of "url"
>>> for #3 I think.
>>>
>>>
>>>
>>>>
>>>>>>> (Re: paths, all paths in plugin.xml should be specified to use /
>>>>>>> always, URLs and filesystem paths both. It's the tool's job to properly
>>>>>>> split and convert to Windows backslashes where appropriate. I'm sure there
>>>>>>> are a few places where we've gotten this wrong; Windows users please file
>>>>>>> bugs if you run into them. Mostly, though, I was careful to split/join
>>>>>>> explicitly on / or use path.foo functions appropriately.)
>>>>>>>
>>>>>>> Thoughts on that proposal?
>>>>>>>
>>>>>>> Braden
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>>>>
>>>>>>>> For now, yes, but we could extend that without breaking anything,
>>>>>>>> no?
>>>>>>>>  Right now url="../etc" would be invalid, so we could safely add
>>>>>>>> support
>>>>>>>> for urls with leading "..", and make that relative to current
>>>>>>>> plugin.
>>>>>>>>
>>>>>>>> url="." would still do what it does today, but could likely be
>>>>>>>> deprecated
>>>>>>>> along with subdir and commit attributes (or at least document the
>>>>>>>> limitation of that approach somewhere).
>>>>>>>>
>>>>>>>> Not sure about making the form url="./etc" be relative to URL root
>>>>>>>> or
>>>>>>>> current plugin, but I don't see why that form would ever be useful
>>>>>>>> anyway.
>>>>>>>>
>>>>>>>> -Michal
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> > Because for the hosted case, the URL points to where the repo is,
>>>>>>>> not to
>>>>>>>> > where the plugin is.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <
>>>>>>>> mmocny@chromium.org> wrote:
>>>>>>>> >
>>>>>>>> >> If URL can be relative, why do we need a new path parameter?
>>>>>>>>  All we
>>>>>>>> >> would need is to treat leading ./ or ../ as relative to the
>>>>>>>> plugin not
>>>>>>>> >> root, which I think is fine.
>>>>>>>> >>
>>>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to make
>>>>>>>> sure all
>>>>>>>> >> the cases are handled.
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
>>>>>>>> agrieve@chromium.org>wrote:
>>>>>>>> >>
>>>>>>>> >>> Agree the use-case is valid. Here's a variation on (1) that I
>>>>>>>> think is
>>>>>>>> >>> marginally nicer:
>>>>>>>> >>>
>>>>>>>> >>> url="." to be made optional, but default value is "."
>>>>>>>> >>> subdir="" works only with git repos and is always relative to
>>>>>>>> the root
>>>>>>>> >>> of the repo.
>>>>>>>> >>> path="" works with git repos or local paths and is relative to
>>>>>>>> the
>>>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or
>>>>>>>> "subdir" if you
>>>>>>>> >>> have "path".
>>>>>>>> >>>
>>>>>>>> >>> Support was just added for specifying commit and path within
>>>>>>>> url. So, we
>>>>>>>> >>> could actually just deprecate "subdir". and have "url" or "path"
>>>>>>>> >>>
>>>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative to
>>>>>>>> the
>>>>>>>> >>> current plugin's git url.
>>>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current URL
>>>>>>>> >>> (cordova-labs style)
>>>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the
>>>>>>>> current URL
>>>>>>>> >>> plus a subdir within it.
>>>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just
>>>>>>>> want to
>>>>>>>> >>> set the path)
>>>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the current
>>>>>>>> plugin is
>>>>>>>> >>> from git, then be careful not to go above the git root.
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <
>>>>>>>> mmocny@chromium.org>wrote:
>>>>>>>> >>>
>>>>>>>> >>>> Mulling this over a bit, I think I would like a solution for
>>>>>>>> specifying
>>>>>>>> >>>> dependancies that would work regardless of where/how the
>>>>>>>> plugins are
>>>>>>>> >>>> hosted, git or local.  If you had:
>>>>>>>> >>>>
>>>>>>>> >>>> BB_PLUGINS/
>>>>>>>> >>>> - plug1/
>>>>>>>> >>>> - plug2/
>>>>>>>> >>>> ...
>>>>>>>> >>>>
>>>>>>>> >>>> (and plug1 depends on plug2), then:
>>>>>>>> >>>>
>>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..
>>>>>>>> cordova
>>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>>>>> >>>>
>>>>>>>> >>>> ..should both work without changing all of the dependency tags
>>>>>>>> in plug1.
>>>>>>>> >>>>  Actually, the plugin author should not have an explicit say
>>>>>>>> in how a
>>>>>>>> >>>> user
>>>>>>>> >>>> manages these directories (except in the directory structure).
>>>>>>>>  Note
>>>>>>>> >>>> that
>>>>>>>> >>>> this situation applies whenever a user clones your plugin repo
>>>>>>>> to
>>>>>>>> >>>> locally,
>>>>>>>> >>>> or for the reverse direction, when ever they add your plugins
>>>>>>>> into their
>>>>>>>> >>>> teams' git repo.
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> Right now, thats not possible, because when installing from
>>>>>>>> local path
>>>>>>>> >>>> with
>>>>>>>> >>>> url="." there is no way to know which of the plugins parent
>>>>>>>> directories
>>>>>>>> >>>> to
>>>>>>>> >>>> consider as the "root".  We could resolve this using several
>>>>>>>> ways, among
>>>>>>>> >>>> them:
>>>>>>>> >>>>
>>>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path
>>>>>>>> relative to this
>>>>>>>> >>>> plugin" (note however, that I propose it also works when
>>>>>>>> installing
>>>>>>>> >>>> from a
>>>>>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>>>>>> >>>>
>>>>>>>> >>>> (2) Support a new special file to "mark" the plugin root dir
>>>>>>>> so we can
>>>>>>>> >>>> walk
>>>>>>>> >>>> the directory tree to find the valid target for url="." (ie,
>>>>>>>> replace the
>>>>>>>> >>>> requirement for a .git with a requirement for a .cordova_repo,
>>>>>>>> which BB
>>>>>>>> >>>> and
>>>>>>>> >>>> others could place within their plugin bundle).
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> I like (1).
>>>>>>>> >>>>
>>>>>>>> >>>> -Michal
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <
>>>>>>>> mmocny@chromium.org>
>>>>>>>> >>>> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> > Sounds reasonable to me.
>>>>>>>> >>>> >
>>>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't
>>>>>>>> do what
>>>>>>>> >>>> you
>>>>>>>> >>>> > request when the url for the original plugin was a local
>>>>>>>> path?  Maybe
>>>>>>>> >>>> just
>>>>>>>> >>>> > a bug?
>>>>>>>> >>>> >
>>>>>>>> >>>> > -Michal
>>>>>>>> >>>> >
>>>>>>>> >>>> >
>>>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>>>>> >>>> >
>>>>>>>> >>>> >> We were working on a redistribution of Cordova that
>>>>>>>> included some
>>>>>>>> >>>> plugins
>>>>>>>> >>>> >> and ran into a use-case not covered by the current plugin
>>>>>>>> spec.[1]
>>>>>>>> >>>> >>
>>>>>>>> >>>> >> Currently there are two ways to specify a dependency
>>>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which
>>>>>>>> plugman will
>>>>>>>> >>>> use
>>>>>>>> >>>> >> to clone down a repo and install
>>>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a subdir
>>>>>>>> relative
>>>>>>>> >>>> to
>>>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse to
>>>>>>>> find the
>>>>>>>> >>>> root and
>>>>>>>> >>>> >> install from there.
>>>>>>>> >>>> >>
>>>>>>>> >>>> >> I would like to propose a third way which would be relative
>>>>>>>> to the
>>>>>>>> >>>> >> current install and not use git at all
>>>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir
>>>>>>>> relative to the
>>>>>>>> >>>> >> current plugin.xml.
>>>>>>>> >>>> >>
>>>>>>>> >>>> >> This would allow us to distribute a version of cordova with
>>>>>>>> plugins
>>>>>>>> >>>> to
>>>>>>>> >>>> >> anyone without an unnecessary requirement on git
>>>>>>>> (considering the
>>>>>>>> >>>> plugins
>>>>>>>> >>>> >> are fully installed)
>>>>>>>> >>>> >>
>>>>>>>> >>>> >>
>>>>>>>> >>>> >>
>>>>>>>> >>>> >> 1.
>>>>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>>>>> >>>> >>
>>>>>>>> >>>> >>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> >>>> >> This transmission (including any attachments) may contain
>>>>>>>> >>>> confidential
>>>>>>>> >>>> >> information, privileged material (including material
>>>>>>>> protected by the
>>>>>>>> >>>> >> solicitor-client or other applicable privileges), or
>>>>>>>> constitute
>>>>>>>> >>>> non-public
>>>>>>>> >>>> >> information. Any use of this information by anyone other
>>>>>>>> than the
>>>>>>>> >>>> intended
>>>>>>>> >>>> >> recipient is prohibited. If you have received this
>>>>>>>> transmission in
>>>>>>>> >>>> error,
>>>>>>>> >>>> >> please immediately reply to the sender and delete this
>>>>>>>> information
>>>>>>>> >>>> from
>>>>>>>> >>>> >> your system. Use, dissemination, distribution, or
>>>>>>>> reproduction of
>>>>>>>> >>>> this
>>>>>>>> >>>> >> transmission by unintended recipients is not authorized and
>>>>>>>> may be
>>>>>>>> >>>> unlawful.
>>>>>>>> >>>> >>
>>>>>>>> >>>> >
>>>>>>>> >>>> >
>>>>>>>> >>>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Michal Mocny <mm...@chromium.org>.
I'm not convinced that all use cases cannot be handled with a single
attribute.  Maybe url / path are the wrong names, maybe a single src="".


On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson <br...@chromium.org>wrote:

> Sure, I can work with path="" instead. What happens if (when) a user
> supplies both?
>
>
> On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <br...@chromium.org>wrote:
>>
>>> I believe the current logic is "a plugin with this ID is already
>>> installed, so stop". That interacts badly with different versions.
>>>
>>> Braden
>>>
>>>
>>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>
>>>> .. but either way if we add support for filesystem-relative paths and
>>>> they work when fetching the original plugin either from git or locally,
>>>> then we are done.
>>>>
>>>> As an aside, when a plugin lists its dependency as explicitly from a
>>>> git url, can the user somehow override that to install from a local copy?
>>>>  Perhaps if they manually install the dependant first, then we won't go
>>>> fetch from git needlessly?  How does that interact with different versions
>>>> of the plugin?
>>>>
>>>> -Michal
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>
>>>>> Jeffrey's point at the start of this thread is that he isn't using a
>>>>> git repo locally, so there is no .git folder to find.
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
>>>>> braden@chromium.org> wrote:
>>>>>
>>>>>> I like where this is generally going, but I want to correct one
>>>>>> mistake Michal made. There /is/ a way to know which directory above a
>>>>>> plugin is the root. The code uses git to find the .git directory, which is
>>>>>> taken to be the root from which the subdir is relative. That means that in
>>>>>> the case of url="." and url="https://github.com/..." the subdir has
>>>>>> the same meaning: relative to the git root.
>>>>>>
>>>>>> I like the path="" option. I agree that subdir and ref could be
>>>>>> dropped, since they can be specified as part of the URL. On the other hand,
>>>>>> there's no harm in keeping them around for compatibility.
>>>>>>
>>>>>> I suggest:
>>>>>>
>>>>>> 1. Remote git, all in URL: url="
>>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>>>  2. Remote git, separate parameters: url="
>>>>>> https://github.com/foo/bar.git" subdir="sub/dir" ref="somebranch"
>>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir"
>>>>>> ref="somebranch"      (we can probably support all-in-URL here too)
>>>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no
>>>>>> all-in-URL here; there's no need for the other parameters in this case)
>>>>>>
>>>>>> The last can be differentiated from the others easily enough, the
>>>>>> logic is:
>>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a remote
>>>>>> git. This is already supported fully.
>>>>>> 2. Is the url === "."? If so, it's a local git-relative path. Already
>>>>>> fully supported.
>>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new plugin
>>>>>> can be found at path.resolve(path_to_current_plugin, dep.attrib.url);
>>>>>> Though some path-separator tweaking is always required.
>>>>>>
>>>>> I think this will be confusing. For case #3, you have the "url"
>> attribute that defines the path, and not the url. I would look at this and
>> interpret it as a relative URL, and the URL is meant to tell you where the
>> git repo is. It would be much clearer to call this "path" instead of "url"
>> for #3 I think.
>>
>>
>>
>>>
>>>>>> (Re: paths, all paths in plugin.xml should be specified to use /
>>>>>> always, URLs and filesystem paths both. It's the tool's job to properly
>>>>>> split and convert to Windows backslashes where appropriate. I'm sure there
>>>>>> are a few places where we've gotten this wrong; Windows users please file
>>>>>> bugs if you run into them. Mostly, though, I was careful to split/join
>>>>>> explicitly on / or use path.foo functions appropriately.)
>>>>>>
>>>>>> Thoughts on that proposal?
>>>>>>
>>>>>> Braden
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>>>
>>>>>>> For now, yes, but we could extend that without breaking anything, no?
>>>>>>>  Right now url="../etc" would be invalid, so we could safely add
>>>>>>> support
>>>>>>> for urls with leading "..", and make that relative to current plugin.
>>>>>>>
>>>>>>> url="." would still do what it does today, but could likely be
>>>>>>> deprecated
>>>>>>> along with subdir and commit attributes (or at least document the
>>>>>>> limitation of that approach somewhere).
>>>>>>>
>>>>>>> Not sure about making the form url="./etc" be relative to URL root or
>>>>>>> current plugin, but I don't see why that form would ever be useful
>>>>>>> anyway.
>>>>>>>
>>>>>>> -Michal
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Because for the hosted case, the URL points to where the repo is,
>>>>>>> not to
>>>>>>> > where the plugin is.
>>>>>>> >
>>>>>>> >
>>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> >> If URL can be relative, why do we need a new path parameter?  All
>>>>>>> we
>>>>>>> >> would need is to treat leading ./ or ../ as relative to the
>>>>>>> plugin not
>>>>>>> >> root, which I think is fine.
>>>>>>> >>
>>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to make
>>>>>>> sure all
>>>>>>> >> the cases are handled.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
>>>>>>> agrieve@chromium.org>wrote:
>>>>>>> >>
>>>>>>> >>> Agree the use-case is valid. Here's a variation on (1) that I
>>>>>>> think is
>>>>>>> >>> marginally nicer:
>>>>>>> >>>
>>>>>>> >>> url="." to be made optional, but default value is "."
>>>>>>> >>> subdir="" works only with git repos and is always relative to
>>>>>>> the root
>>>>>>> >>> of the repo.
>>>>>>> >>> path="" works with git repos or local paths and is relative to
>>>>>>> the
>>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or
>>>>>>> "subdir" if you
>>>>>>> >>> have "path".
>>>>>>> >>>
>>>>>>> >>> Support was just added for specifying commit and path within
>>>>>>> url. So, we
>>>>>>> >>> could actually just deprecate "subdir". and have "url" or "path"
>>>>>>> >>>
>>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative to the
>>>>>>> >>> current plugin's git url.
>>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current URL
>>>>>>> >>> (cordova-labs style)
>>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the
>>>>>>> current URL
>>>>>>> >>> plus a subdir within it.
>>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just
>>>>>>> want to
>>>>>>> >>> set the path)
>>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the current
>>>>>>> plugin is
>>>>>>> >>> from git, then be careful not to go above the git root.
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <
>>>>>>> mmocny@chromium.org>wrote:
>>>>>>> >>>
>>>>>>> >>>> Mulling this over a bit, I think I would like a solution for
>>>>>>> specifying
>>>>>>> >>>> dependancies that would work regardless of where/how the
>>>>>>> plugins are
>>>>>>> >>>> hosted, git or local.  If you had:
>>>>>>> >>>>
>>>>>>> >>>> BB_PLUGINS/
>>>>>>> >>>> - plug1/
>>>>>>> >>>> - plug2/
>>>>>>> >>>> ...
>>>>>>> >>>>
>>>>>>> >>>> (and plug1 depends on plug2), then:
>>>>>>> >>>>
>>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..
>>>>>>> cordova
>>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>>>> >>>>
>>>>>>> >>>> ..should both work without changing all of the dependency tags
>>>>>>> in plug1.
>>>>>>> >>>>  Actually, the plugin author should not have an explicit say in
>>>>>>> how a
>>>>>>> >>>> user
>>>>>>> >>>> manages these directories (except in the directory structure).
>>>>>>>  Note
>>>>>>> >>>> that
>>>>>>> >>>> this situation applies whenever a user clones your plugin repo
>>>>>>> to
>>>>>>> >>>> locally,
>>>>>>> >>>> or for the reverse direction, when ever they add your plugins
>>>>>>> into their
>>>>>>> >>>> teams' git repo.
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> Right now, thats not possible, because when installing from
>>>>>>> local path
>>>>>>> >>>> with
>>>>>>> >>>> url="." there is no way to know which of the plugins parent
>>>>>>> directories
>>>>>>> >>>> to
>>>>>>> >>>> consider as the "root".  We could resolve this using several
>>>>>>> ways, among
>>>>>>> >>>> them:
>>>>>>> >>>>
>>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path
>>>>>>> relative to this
>>>>>>> >>>> plugin" (note however, that I propose it also works when
>>>>>>> installing
>>>>>>> >>>> from a
>>>>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>>>>> >>>>
>>>>>>> >>>> (2) Support a new special file to "mark" the plugin root dir so
>>>>>>> we can
>>>>>>> >>>> walk
>>>>>>> >>>> the directory tree to find the valid target for url="." (ie,
>>>>>>> replace the
>>>>>>> >>>> requirement for a .git with a requirement for a .cordova_repo,
>>>>>>> which BB
>>>>>>> >>>> and
>>>>>>> >>>> others could place within their plugin bundle).
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> I like (1).
>>>>>>> >>>>
>>>>>>> >>>> -Michal
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <
>>>>>>> mmocny@chromium.org>
>>>>>>> >>>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> > Sounds reasonable to me.
>>>>>>> >>>> >
>>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't
>>>>>>> do what
>>>>>>> >>>> you
>>>>>>> >>>> > request when the url for the original plugin was a local
>>>>>>> path?  Maybe
>>>>>>> >>>> just
>>>>>>> >>>> > a bug?
>>>>>>> >>>> >
>>>>>>> >>>> > -Michal
>>>>>>> >>>> >
>>>>>>> >>>> >
>>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>>>> >>>> >
>>>>>>> >>>> >> We were working on a redistribution of Cordova that included
>>>>>>> some
>>>>>>> >>>> plugins
>>>>>>> >>>> >> and ran into a use-case not covered by the current plugin
>>>>>>> spec.[1]
>>>>>>> >>>> >>
>>>>>>> >>>> >> Currently there are two ways to specify a dependency
>>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which
>>>>>>> plugman will
>>>>>>> >>>> use
>>>>>>> >>>> >> to clone down a repo and install
>>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a subdir
>>>>>>> relative
>>>>>>> >>>> to
>>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse to
>>>>>>> find the
>>>>>>> >>>> root and
>>>>>>> >>>> >> install from there.
>>>>>>> >>>> >>
>>>>>>> >>>> >> I would like to propose a third way which would be relative
>>>>>>> to the
>>>>>>> >>>> >> current install and not use git at all
>>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir
>>>>>>> relative to the
>>>>>>> >>>> >> current plugin.xml.
>>>>>>> >>>> >>
>>>>>>> >>>> >> This would allow us to distribute a version of cordova with
>>>>>>> plugins
>>>>>>> >>>> to
>>>>>>> >>>> >> anyone without an unnecessary requirement on git
>>>>>>> (considering the
>>>>>>> >>>> plugins
>>>>>>> >>>> >> are fully installed)
>>>>>>> >>>> >>
>>>>>>> >>>> >>
>>>>>>> >>>> >>
>>>>>>> >>>> >> 1.
>>>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>>>> >>>> >>
>>>>>>> >>>> >>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> >>>> >> This transmission (including any attachments) may contain
>>>>>>> >>>> confidential
>>>>>>> >>>> >> information, privileged material (including material
>>>>>>> protected by the
>>>>>>> >>>> >> solicitor-client or other applicable privileges), or
>>>>>>> constitute
>>>>>>> >>>> non-public
>>>>>>> >>>> >> information. Any use of this information by anyone other
>>>>>>> than the
>>>>>>> >>>> intended
>>>>>>> >>>> >> recipient is prohibited. If you have received this
>>>>>>> transmission in
>>>>>>> >>>> error,
>>>>>>> >>>> >> please immediately reply to the sender and delete this
>>>>>>> information
>>>>>>> >>>> from
>>>>>>> >>>> >> your system. Use, dissemination, distribution, or
>>>>>>> reproduction of
>>>>>>> >>>> this
>>>>>>> >>>> >> transmission by unintended recipients is not authorized and
>>>>>>> may be
>>>>>>> >>>> unlawful.
>>>>>>> >>>> >>
>>>>>>> >>>> >
>>>>>>> >>>> >
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Braden Shepherdson <br...@chromium.org>.
Sure, I can work with path="" instead. What happens if (when) a user
supplies both?


On Wed, Sep 4, 2013 at 1:19 PM, Andrew Grieve <ag...@chromium.org> wrote:

>
>
>
> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> I believe the current logic is "a plugin with this ID is already
>> installed, so stop". That interacts badly with different versions.
>>
>> Braden
>>
>>
>> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny <mm...@chromium.org>wrote:
>>
>>> .. but either way if we add support for filesystem-relative paths and
>>> they work when fetching the original plugin either from git or locally,
>>> then we are done.
>>>
>>> As an aside, when a plugin lists its dependency as explicitly from a git
>>> url, can the user somehow override that to install from a local copy?
>>>  Perhaps if they manually install the dependant first, then we won't go
>>> fetch from git needlessly?  How does that interact with different versions
>>> of the plugin?
>>>
>>> -Michal
>>>
>>>
>>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>
>>>> Jeffrey's point at the start of this thread is that he isn't using a
>>>> git repo locally, so there is no .git folder to find.
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <
>>>> braden@chromium.org> wrote:
>>>>
>>>>> I like where this is generally going, but I want to correct one
>>>>> mistake Michal made. There /is/ a way to know which directory above a
>>>>> plugin is the root. The code uses git to find the .git directory, which is
>>>>> taken to be the root from which the subdir is relative. That means that in
>>>>> the case of url="." and url="https://github.com/..." the subdir has
>>>>> the same meaning: relative to the git root.
>>>>>
>>>>> I like the path="" option. I agree that subdir and ref could be
>>>>> dropped, since they can be specified as part of the URL. On the other hand,
>>>>> there's no harm in keeping them around for compatibility.
>>>>>
>>>>> I suggest:
>>>>>
>>>>> 1. Remote git, all in URL: url="
>>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>>  2. Remote git, separate parameters: url="
>>>>> https://github.com/foo/bar.git" subdir="sub/dir" ref="somebranch"
>>>>> 3. Local, git-root-relative: url="." subdir="sub/dir" ref="somebranch"
>>>>>      (we can probably support all-in-URL here too)
>>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no all-in-URL
>>>>> here; there's no need for the other parameters in this case)
>>>>>
>>>>> The last can be differentiated from the others easily enough, the
>>>>> logic is:
>>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a remote
>>>>> git. This is already supported fully.
>>>>> 2. Is the url === "."? If so, it's a local git-relative path. Already
>>>>> fully supported.
>>>>> 3. Otherwise, it's a filesystem-relative path, and so the new plugin
>>>>> can be found at path.resolve(path_to_current_plugin, dep.attrib.url);
>>>>> Though some path-separator tweaking is always required.
>>>>>
>>>> I think this will be confusing. For case #3, you have the "url"
> attribute that defines the path, and not the url. I would look at this and
> interpret it as a relative URL, and the URL is meant to tell you where the
> git repo is. It would be much clearer to call this "path" instead of "url"
> for #3 I think.
>
>
>
>>
>>>>> (Re: paths, all paths in plugin.xml should be specified to use /
>>>>> always, URLs and filesystem paths both. It's the tool's job to properly
>>>>> split and convert to Windows backslashes where appropriate. I'm sure there
>>>>> are a few places where we've gotten this wrong; Windows users please file
>>>>> bugs if you run into them. Mostly, though, I was careful to split/join
>>>>> explicitly on / or use path.foo functions appropriately.)
>>>>>
>>>>> Thoughts on that proposal?
>>>>>
>>>>> Braden
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>>
>>>>>> For now, yes, but we could extend that without breaking anything, no?
>>>>>>  Right now url="../etc" would be invalid, so we could safely add
>>>>>> support
>>>>>> for urls with leading "..", and make that relative to current plugin.
>>>>>>
>>>>>> url="." would still do what it does today, but could likely be
>>>>>> deprecated
>>>>>> along with subdir and commit attributes (or at least document the
>>>>>> limitation of that approach somewhere).
>>>>>>
>>>>>> Not sure about making the form url="./etc" be relative to URL root or
>>>>>> current plugin, but I don't see why that form would ever be useful
>>>>>> anyway.
>>>>>>
>>>>>> -Michal
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
>>>>>> wrote:
>>>>>>
>>>>>> > Because for the hosted case, the URL points to where the repo is,
>>>>>> not to
>>>>>> > where the plugin is.
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org>
>>>>>> wrote:
>>>>>> >
>>>>>> >> If URL can be relative, why do we need a new path parameter?  All
>>>>>> we
>>>>>> >> would need is to treat leading ./ or ../ as relative to the plugin
>>>>>> not
>>>>>> >> root, which I think is fine.
>>>>>> >>
>>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to make
>>>>>> sure all
>>>>>> >> the cases are handled.
>>>>>> >>
>>>>>> >>
>>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
>>>>>> agrieve@chromium.org>wrote:
>>>>>> >>
>>>>>> >>> Agree the use-case is valid. Here's a variation on (1) that I
>>>>>> think is
>>>>>> >>> marginally nicer:
>>>>>> >>>
>>>>>> >>> url="." to be made optional, but default value is "."
>>>>>> >>> subdir="" works only with git repos and is always relative to the
>>>>>> root
>>>>>> >>> of the repo.
>>>>>> >>> path="" works with git repos or local paths and is relative to the
>>>>>> >>> plugin.xml of the current plugin. You can't have "url" or
>>>>>> "subdir" if you
>>>>>> >>> have "path".
>>>>>> >>>
>>>>>> >>> Support was just added for specifying commit and path within url.
>>>>>> So, we
>>>>>> >>> could actually just deprecate "subdir". and have "url" or "path"
>>>>>> >>>
>>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative to the
>>>>>> >>> current plugin's git url.
>>>>>> >>> E.g.: url="#branch2" would specify a branch on the current URL
>>>>>> >>> (cordova-labs style)
>>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the
>>>>>> current URL
>>>>>> >>> plus a subdir within it.
>>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just
>>>>>> want to
>>>>>> >>> set the path)
>>>>>> >>> E.g.: path="../B" is always a relative fs path. If the current
>>>>>> plugin is
>>>>>> >>> from git, then be careful not to go above the git root.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <
>>>>>> mmocny@chromium.org>wrote:
>>>>>> >>>
>>>>>> >>>> Mulling this over a bit, I think I would like a solution for
>>>>>> specifying
>>>>>> >>>> dependancies that would work regardless of where/how the plugins
>>>>>> are
>>>>>> >>>> hosted, git or local.  If you had:
>>>>>> >>>>
>>>>>> >>>> BB_PLUGINS/
>>>>>> >>>> - plug1/
>>>>>> >>>> - plug2/
>>>>>> >>>> ...
>>>>>> >>>>
>>>>>> >>>> (and plug1 depends on plug2), then:
>>>>>> >>>>
>>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..
>>>>>> cordova
>>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>>> >>>>
>>>>>> >>>> ..should both work without changing all of the dependency tags
>>>>>> in plug1.
>>>>>> >>>>  Actually, the plugin author should not have an explicit say in
>>>>>> how a
>>>>>> >>>> user
>>>>>> >>>> manages these directories (except in the directory structure).
>>>>>>  Note
>>>>>> >>>> that
>>>>>> >>>> this situation applies whenever a user clones your plugin repo to
>>>>>> >>>> locally,
>>>>>> >>>> or for the reverse direction, when ever they add your plugins
>>>>>> into their
>>>>>> >>>> teams' git repo.
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> Right now, thats not possible, because when installing from
>>>>>> local path
>>>>>> >>>> with
>>>>>> >>>> url="." there is no way to know which of the plugins parent
>>>>>> directories
>>>>>> >>>> to
>>>>>> >>>> consider as the "root".  We could resolve this using several
>>>>>> ways, among
>>>>>> >>>> them:
>>>>>> >>>>
>>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path relative
>>>>>> to this
>>>>>> >>>> plugin" (note however, that I propose it also works when
>>>>>> installing
>>>>>> >>>> from a
>>>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>>>> >>>>
>>>>>> >>>> (2) Support a new special file to "mark" the plugin root dir so
>>>>>> we can
>>>>>> >>>> walk
>>>>>> >>>> the directory tree to find the valid target for url="." (ie,
>>>>>> replace the
>>>>>> >>>> requirement for a .git with a requirement for a .cordova_repo,
>>>>>> which BB
>>>>>> >>>> and
>>>>>> >>>> others could place within their plugin bundle).
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> I like (1).
>>>>>> >>>>
>>>>>> >>>> -Michal
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <
>>>>>> mmocny@chromium.org>
>>>>>> >>>> wrote:
>>>>>> >>>>
>>>>>> >>>> > Sounds reasonable to me.
>>>>>> >>>> >
>>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do
>>>>>> what
>>>>>> >>>> you
>>>>>> >>>> > request when the url for the original plugin was a local path?
>>>>>>  Maybe
>>>>>> >>>> just
>>>>>> >>>> > a bug?
>>>>>> >>>> >
>>>>>> >>>> > -Michal
>>>>>> >>>> >
>>>>>> >>>> >
>>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>>> >>>> >
>>>>>> >>>> >> We were working on a redistribution of Cordova that included
>>>>>> some
>>>>>> >>>> plugins
>>>>>> >>>> >> and ran into a use-case not covered by the current plugin
>>>>>> spec.[1]
>>>>>> >>>> >>
>>>>>> >>>> >> Currently there are two ways to specify a dependency
>>>>>> >>>> >> 1. Using a combination of url, commit and subdir which
>>>>>> plugman will
>>>>>> >>>> use
>>>>>> >>>> >> to clone down a repo and install
>>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a subdir
>>>>>> relative
>>>>>> >>>> to
>>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse to find
>>>>>> the
>>>>>> >>>> root and
>>>>>> >>>> >> install from there.
>>>>>> >>>> >>
>>>>>> >>>> >> I would like to propose a third way which would be relative
>>>>>> to the
>>>>>> >>>> >> current install and not use git at all
>>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir
>>>>>> relative to the
>>>>>> >>>> >> current plugin.xml.
>>>>>> >>>> >>
>>>>>> >>>> >> This would allow us to distribute a version of cordova with
>>>>>> plugins
>>>>>> >>>> to
>>>>>> >>>> >> anyone without an unnecessary requirement on git (considering
>>>>>> the
>>>>>> >>>> plugins
>>>>>> >>>> >> are fully installed)
>>>>>> >>>> >>
>>>>>> >>>> >>
>>>>>> >>>> >>
>>>>>> >>>> >> 1.
>>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>>> >>>> >>
>>>>>> >>>> >>
>>>>>> ---------------------------------------------------------------------
>>>>>> >>>> >> This transmission (including any attachments) may contain
>>>>>> >>>> confidential
>>>>>> >>>> >> information, privileged material (including material
>>>>>> protected by the
>>>>>> >>>> >> solicitor-client or other applicable privileges), or
>>>>>> constitute
>>>>>> >>>> non-public
>>>>>> >>>> >> information. Any use of this information by anyone other than
>>>>>> the
>>>>>> >>>> intended
>>>>>> >>>> >> recipient is prohibited. If you have received this
>>>>>> transmission in
>>>>>> >>>> error,
>>>>>> >>>> >> please immediately reply to the sender and delete this
>>>>>> information
>>>>>> >>>> from
>>>>>> >>>> >> your system. Use, dissemination, distribution, or
>>>>>> reproduction of
>>>>>> >>>> this
>>>>>> >>>> >> transmission by unintended recipients is not authorized and
>>>>>> may be
>>>>>> >>>> unlawful.
>>>>>> >>>> >>
>>>>>> >>>> >
>>>>>> >>>> >
>>>>>> >>>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <br...@chromium.org>wrote:

> I believe the current logic is "a plugin with this ID is already
> installed, so stop". That interacts badly with different versions.
>
> Braden
>
>
> On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny <mm...@chromium.org> wrote:
>
>> .. but either way if we add support for filesystem-relative paths and
>> they work when fetching the original plugin either from git or locally,
>> then we are done.
>>
>> As an aside, when a plugin lists its dependency as explicitly from a git
>> url, can the user somehow override that to install from a local copy?
>>  Perhaps if they manually install the dependant first, then we won't go
>> fetch from git needlessly?  How does that interact with different versions
>> of the plugin?
>>
>> -Michal
>>
>>
>> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny <mm...@chromium.org>wrote:
>>
>>> Jeffrey's point at the start of this thread is that he isn't using a git
>>> repo locally, so there is no .git folder to find.
>>>
>>>
>>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <braden@chromium.org
>>> > wrote:
>>>
>>>> I like where this is generally going, but I want to correct one mistake
>>>> Michal made. There /is/ a way to know which directory above a plugin is the
>>>> root. The code uses git to find the .git directory, which is taken to be
>>>> the root from which the subdir is relative. That means that in the case of
>>>> url="." and url="https://github.com/..." the subdir has the same
>>>> meaning: relative to the git root.
>>>>
>>>> I like the path="" option. I agree that subdir and ref could be
>>>> dropped, since they can be specified as part of the URL. On the other hand,
>>>> there's no harm in keeping them around for compatibility.
>>>>
>>>> I suggest:
>>>>
>>>> 1. Remote git, all in URL: url="
>>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>>  2. Remote git, separate parameters: url="
>>>> https://github.com/foo/bar.git" subdir="sub/dir" ref="somebranch"
>>>> 3. Local, git-root-relative: url="." subdir="sub/dir" ref="somebranch"
>>>>      (we can probably support all-in-URL here too)
>>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no all-in-URL
>>>> here; there's no need for the other parameters in this case)
>>>>
>>>> The last can be differentiated from the others easily enough, the logic
>>>> is:
>>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a remote
>>>> git. This is already supported fully.
>>>> 2. Is the url === "."? If so, it's a local git-relative path. Already
>>>> fully supported.
>>>> 3. Otherwise, it's a filesystem-relative path, and so the new plugin
>>>> can be found at path.resolve(path_to_current_plugin, dep.attrib.url);
>>>> Though some path-separator tweaking is always required.
>>>>
>>> I think this will be confusing. For case #3, you have the "url"
attribute that defines the path, and not the url. I would look at this and
interpret it as a relative URL, and the URL is meant to tell you where the
git repo is. It would be much clearer to call this "path" instead of "url"
for #3 I think.



>
>>>> (Re: paths, all paths in plugin.xml should be specified to use /
>>>> always, URLs and filesystem paths both. It's the tool's job to properly
>>>> split and convert to Windows backslashes where appropriate. I'm sure there
>>>> are a few places where we've gotten this wrong; Windows users please file
>>>> bugs if you run into them. Mostly, though, I was careful to split/join
>>>> explicitly on / or use path.foo functions appropriately.)
>>>>
>>>> Thoughts on that proposal?
>>>>
>>>> Braden
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>>
>>>>> For now, yes, but we could extend that without breaking anything, no?
>>>>>  Right now url="../etc" would be invalid, so we could safely add
>>>>> support
>>>>> for urls with leading "..", and make that relative to current plugin.
>>>>>
>>>>> url="." would still do what it does today, but could likely be
>>>>> deprecated
>>>>> along with subdir and commit attributes (or at least document the
>>>>> limitation of that approach somewhere).
>>>>>
>>>>> Not sure about making the form url="./etc" be relative to URL root or
>>>>> current plugin, but I don't see why that form would ever be useful
>>>>> anyway.
>>>>>
>>>>> -Michal
>>>>>
>>>>>
>>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
>>>>> wrote:
>>>>>
>>>>> > Because for the hosted case, the URL points to where the repo is,
>>>>> not to
>>>>> > where the plugin is.
>>>>> >
>>>>> >
>>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org>
>>>>> wrote:
>>>>> >
>>>>> >> If URL can be relative, why do we need a new path parameter?  All we
>>>>> >> would need is to treat leading ./ or ../ as relative to the plugin
>>>>> not
>>>>> >> root, which I think is fine.
>>>>> >>
>>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to make
>>>>> sure all
>>>>> >> the cases are handled.
>>>>> >>
>>>>> >>
>>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <
>>>>> agrieve@chromium.org>wrote:
>>>>> >>
>>>>> >>> Agree the use-case is valid. Here's a variation on (1) that I
>>>>> think is
>>>>> >>> marginally nicer:
>>>>> >>>
>>>>> >>> url="." to be made optional, but default value is "."
>>>>> >>> subdir="" works only with git repos and is always relative to the
>>>>> root
>>>>> >>> of the repo.
>>>>> >>> path="" works with git repos or local paths and is relative to the
>>>>> >>> plugin.xml of the current plugin. You can't have "url" or "subdir"
>>>>> if you
>>>>> >>> have "path".
>>>>> >>>
>>>>> >>> Support was just added for specifying commit and path within url.
>>>>> So, we
>>>>> >>> could actually just deprecate "subdir". and have "url" or "path"
>>>>> >>>
>>>>> >>> E.g.: url="some/path.git" would specify a git URL relative to the
>>>>> >>> current plugin's git url.
>>>>> >>> E.g.: url="#branch2" would specify a branch on the current URL
>>>>> >>> (cordova-labs style)
>>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the
>>>>> current URL
>>>>> >>> plus a subdir within it.
>>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just
>>>>> want to
>>>>> >>> set the path)
>>>>> >>> E.g.: path="../B" is always a relative fs path. If the current
>>>>> plugin is
>>>>> >>> from git, then be careful not to go above the git root.
>>>>> >>>
>>>>> >>>
>>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mmocny@chromium.org
>>>>> >wrote:
>>>>> >>>
>>>>> >>>> Mulling this over a bit, I think I would like a solution for
>>>>> specifying
>>>>> >>>> dependancies that would work regardless of where/how the plugins
>>>>> are
>>>>> >>>> hosted, git or local.  If you had:
>>>>> >>>>
>>>>> >>>> BB_PLUGINS/
>>>>> >>>> - plug1/
>>>>> >>>> - plug2/
>>>>> >>>> ...
>>>>> >>>>
>>>>> >>>> (and plug1 depends on plug2), then:
>>>>> >>>>
>>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..
>>>>> cordova
>>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>> >>>>
>>>>> >>>> ..should both work without changing all of the dependency tags in
>>>>> plug1.
>>>>> >>>>  Actually, the plugin author should not have an explicit say in
>>>>> how a
>>>>> >>>> user
>>>>> >>>> manages these directories (except in the directory structure).
>>>>>  Note
>>>>> >>>> that
>>>>> >>>> this situation applies whenever a user clones your plugin repo to
>>>>> >>>> locally,
>>>>> >>>> or for the reverse direction, when ever they add your plugins
>>>>> into their
>>>>> >>>> teams' git repo.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Right now, thats not possible, because when installing from local
>>>>> path
>>>>> >>>> with
>>>>> >>>> url="." there is no way to know which of the plugins parent
>>>>> directories
>>>>> >>>> to
>>>>> >>>> consider as the "root".  We could resolve this using several
>>>>> ways, among
>>>>> >>>> them:
>>>>> >>>>
>>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path relative
>>>>> to this
>>>>> >>>> plugin" (note however, that I propose it also works when
>>>>> installing
>>>>> >>>> from a
>>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>>> >>>>
>>>>> >>>> (2) Support a new special file to "mark" the plugin root dir so
>>>>> we can
>>>>> >>>> walk
>>>>> >>>> the directory tree to find the valid target for url="." (ie,
>>>>> replace the
>>>>> >>>> requirement for a .git with a requirement for a .cordova_repo,
>>>>> which BB
>>>>> >>>> and
>>>>> >>>> others could place within their plugin bundle).
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> I like (1).
>>>>> >>>>
>>>>> >>>> -Michal
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mmocny@chromium.org
>>>>> >
>>>>> >>>> wrote:
>>>>> >>>>
>>>>> >>>> > Sounds reasonable to me.
>>>>> >>>> >
>>>>> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do
>>>>> what
>>>>> >>>> you
>>>>> >>>> > request when the url for the original plugin was a local path?
>>>>>  Maybe
>>>>> >>>> just
>>>>> >>>> > a bug?
>>>>> >>>> >
>>>>> >>>> > -Michal
>>>>> >>>> >
>>>>> >>>> >
>>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>>> >>>> jheifetz@blackberry.com>wrote:
>>>>> >>>> >
>>>>> >>>> >> We were working on a redistribution of Cordova that included
>>>>> some
>>>>> >>>> plugins
>>>>> >>>> >> and ran into a use-case not covered by the current plugin
>>>>> spec.[1]
>>>>> >>>> >>
>>>>> >>>> >> Currently there are two ways to specify a dependency
>>>>> >>>> >> 1. Using a combination of url, commit and subdir which plugman
>>>>> will
>>>>> >>>> use
>>>>> >>>> >> to clone down a repo and install
>>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a subdir
>>>>> relative
>>>>> >>>> to
>>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse to find
>>>>> the
>>>>> >>>> root and
>>>>> >>>> >> install from there.
>>>>> >>>> >>
>>>>> >>>> >> I would like to propose a third way which would be relative to
>>>>> the
>>>>> >>>> >> current install and not use git at all
>>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir relative
>>>>> to the
>>>>> >>>> >> current plugin.xml.
>>>>> >>>> >>
>>>>> >>>> >> This would allow us to distribute a version of cordova with
>>>>> plugins
>>>>> >>>> to
>>>>> >>>> >> anyone without an unnecessary requirement on git (considering
>>>>> the
>>>>> >>>> plugins
>>>>> >>>> >> are fully installed)
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> >>>> >> 1.
>>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> ---------------------------------------------------------------------
>>>>> >>>> >> This transmission (including any attachments) may contain
>>>>> >>>> confidential
>>>>> >>>> >> information, privileged material (including material protected
>>>>> by the
>>>>> >>>> >> solicitor-client or other applicable privileges), or constitute
>>>>> >>>> non-public
>>>>> >>>> >> information. Any use of this information by anyone other than
>>>>> the
>>>>> >>>> intended
>>>>> >>>> >> recipient is prohibited. If you have received this
>>>>> transmission in
>>>>> >>>> error,
>>>>> >>>> >> please immediately reply to the sender and delete this
>>>>> information
>>>>> >>>> from
>>>>> >>>> >> your system. Use, dissemination, distribution, or reproduction
>>>>> of
>>>>> >>>> this
>>>>> >>>> >> transmission by unintended recipients is not authorized and
>>>>> may be
>>>>> >>>> unlawful.
>>>>> >>>> >>
>>>>> >>>> >
>>>>> >>>> >
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Braden Shepherdson <br...@chromium.org>.
I believe the current logic is "a plugin with this ID is already installed,
so stop". That interacts badly with different versions.

Braden


On Wed, Sep 4, 2013 at 11:20 AM, Michal Mocny <mm...@chromium.org> wrote:

> .. but either way if we add support for filesystem-relative paths and they
> work when fetching the original plugin either from git or locally, then we
> are done.
>
> As an aside, when a plugin lists its dependency as explicitly from a git
> url, can the user somehow override that to install from a local copy?
>  Perhaps if they manually install the dependant first, then we won't go
> fetch from git needlessly?  How does that interact with different versions
> of the plugin?
>
> -Michal
>
>
> On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny <mm...@chromium.org> wrote:
>
>> Jeffrey's point at the start of this thread is that he isn't using a git
>> repo locally, so there is no .git folder to find.
>>
>>
>> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <br...@chromium.org>wrote:
>>
>>> I like where this is generally going, but I want to correct one mistake
>>> Michal made. There /is/ a way to know which directory above a plugin is the
>>> root. The code uses git to find the .git directory, which is taken to be
>>> the root from which the subdir is relative. That means that in the case of
>>> url="." and url="https://github.com/..." the subdir has the same
>>> meaning: relative to the git root.
>>>
>>> I like the path="" option. I agree that subdir and ref could be dropped,
>>> since they can be specified as part of the URL. On the other hand, there's
>>> no harm in keeping them around for compatibility.
>>>
>>> I suggest:
>>>
>>> 1. Remote git, all in URL: url="
>>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>>  2. Remote git, separate parameters: url="https://github.com/foo/bar.git"
>>> subdir="sub/dir" ref="somebranch"
>>> 3. Local, git-root-relative: url="." subdir="sub/dir" ref="somebranch"
>>>    (we can probably support all-in-URL here too)
>>> 4. Local, filesystem-relative: url="../../sub/dir"      (no all-in-URL
>>> here; there's no need for the other parameters in this case)
>>>
>>> The last can be differentiated from the others easily enough, the logic
>>> is:
>>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a remote
>>> git. This is already supported fully.
>>> 2. Is the url === "."? If so, it's a local git-relative path. Already
>>> fully supported.
>>> 3. Otherwise, it's a filesystem-relative path, and so the new plugin can
>>> be found at path.resolve(path_to_current_plugin, dep.attrib.url); Though
>>> some path-separator tweaking is always required.
>>>
>>> (Re: paths, all paths in plugin.xml should be specified to use / always,
>>> URLs and filesystem paths both. It's the tool's job to properly split and
>>> convert to Windows backslashes where appropriate. I'm sure there are a few
>>> places where we've gotten this wrong; Windows users please file bugs if you
>>> run into them. Mostly, though, I was careful to split/join explicitly on /
>>> or use path.foo functions appropriately.)
>>>
>>> Thoughts on that proposal?
>>>
>>> Braden
>>>
>>>
>>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org>wrote:
>>>
>>>> For now, yes, but we could extend that without breaking anything, no?
>>>>  Right now url="../etc" would be invalid, so we could safely add support
>>>> for urls with leading "..", and make that relative to current plugin.
>>>>
>>>> url="." would still do what it does today, but could likely be
>>>> deprecated
>>>> along with subdir and commit attributes (or at least document the
>>>> limitation of that approach somewhere).
>>>>
>>>> Not sure about making the form url="./etc" be relative to URL root or
>>>> current plugin, but I don't see why that form would ever be useful
>>>> anyway.
>>>>
>>>> -Michal
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
>>>> wrote:
>>>>
>>>> > Because for the hosted case, the URL points to where the repo is, not
>>>> to
>>>> > where the plugin is.
>>>> >
>>>> >
>>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org>
>>>> wrote:
>>>> >
>>>> >> If URL can be relative, why do we need a new path parameter?  All we
>>>> >> would need is to treat leading ./ or ../ as relative to the plugin
>>>> not
>>>> >> root, which I think is fine.
>>>> >>
>>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to make sure
>>>> all
>>>> >> the cases are handled.
>>>> >>
>>>> >>
>>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <agrieve@chromium.org
>>>> >wrote:
>>>> >>
>>>> >>> Agree the use-case is valid. Here's a variation on (1) that I think
>>>> is
>>>> >>> marginally nicer:
>>>> >>>
>>>> >>> url="." to be made optional, but default value is "."
>>>> >>> subdir="" works only with git repos and is always relative to the
>>>> root
>>>> >>> of the repo.
>>>> >>> path="" works with git repos or local paths and is relative to the
>>>> >>> plugin.xml of the current plugin. You can't have "url" or "subdir"
>>>> if you
>>>> >>> have "path".
>>>> >>>
>>>> >>> Support was just added for specifying commit and path within url.
>>>> So, we
>>>> >>> could actually just deprecate "subdir". and have "url" or "path"
>>>> >>>
>>>> >>> E.g.: url="some/path.git" would specify a git URL relative to the
>>>> >>> current plugin's git url.
>>>> >>> E.g.: url="#branch2" would specify a branch on the current URL
>>>> >>> (cordova-labs style)
>>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the
>>>> current URL
>>>> >>> plus a subdir within it.
>>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just
>>>> want to
>>>> >>> set the path)
>>>> >>> E.g.: path="../B" is always a relative fs path. If the current
>>>> plugin is
>>>> >>> from git, then be careful not to go above the git root.
>>>> >>>
>>>> >>>
>>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mmocny@chromium.org
>>>> >wrote:
>>>> >>>
>>>> >>>> Mulling this over a bit, I think I would like a solution for
>>>> specifying
>>>> >>>> dependancies that would work regardless of where/how the plugins
>>>> are
>>>> >>>> hosted, git or local.  If you had:
>>>> >>>>
>>>> >>>> BB_PLUGINS/
>>>> >>>> - plug1/
>>>> >>>> - plug2/
>>>> >>>> ...
>>>> >>>>
>>>> >>>> (and plug1 depends on plug2), then:
>>>> >>>>
>>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..
>>>> cordova
>>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>> >>>>
>>>> >>>> ..should both work without changing all of the dependency tags in
>>>> plug1.
>>>> >>>>  Actually, the plugin author should not have an explicit say in
>>>> how a
>>>> >>>> user
>>>> >>>> manages these directories (except in the directory structure).
>>>>  Note
>>>> >>>> that
>>>> >>>> this situation applies whenever a user clones your plugin repo to
>>>> >>>> locally,
>>>> >>>> or for the reverse direction, when ever they add your plugins into
>>>> their
>>>> >>>> teams' git repo.
>>>> >>>>
>>>> >>>>
>>>> >>>> Right now, thats not possible, because when installing from local
>>>> path
>>>> >>>> with
>>>> >>>> url="." there is no way to know which of the plugins parent
>>>> directories
>>>> >>>> to
>>>> >>>> consider as the "root".  We could resolve this using several ways,
>>>> among
>>>> >>>> them:
>>>> >>>>
>>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path relative
>>>> to this
>>>> >>>> plugin" (note however, that I propose it also works when installing
>>>> >>>> from a
>>>> >>>> git repo).  Deprecate/warn against using url=".".
>>>> >>>>
>>>> >>>> (2) Support a new special file to "mark" the plugin root dir so we
>>>> can
>>>> >>>> walk
>>>> >>>> the directory tree to find the valid target for url="." (ie,
>>>> replace the
>>>> >>>> requirement for a .git with a requirement for a .cordova_repo,
>>>> which BB
>>>> >>>> and
>>>> >>>> others could place within their plugin bundle).
>>>> >>>>
>>>> >>>>
>>>> >>>> I like (1).
>>>> >>>>
>>>> >>>> -Michal
>>>> >>>>
>>>> >>>>
>>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org>
>>>> >>>> wrote:
>>>> >>>>
>>>> >>>> > Sounds reasonable to me.
>>>> >>>> >
>>>> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do
>>>> what
>>>> >>>> you
>>>> >>>> > request when the url for the original plugin was a local path?
>>>>  Maybe
>>>> >>>> just
>>>> >>>> > a bug?
>>>> >>>> >
>>>> >>>> > -Michal
>>>> >>>> >
>>>> >>>> >
>>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>> >>>> jheifetz@blackberry.com>wrote:
>>>> >>>> >
>>>> >>>> >> We were working on a redistribution of Cordova that included
>>>> some
>>>> >>>> plugins
>>>> >>>> >> and ran into a use-case not covered by the current plugin
>>>> spec.[1]
>>>> >>>> >>
>>>> >>>> >> Currently there are two ways to specify a dependency
>>>> >>>> >> 1. Using a combination of url, commit and subdir which plugman
>>>> will
>>>> >>>> use
>>>> >>>> >> to clone down a repo and install
>>>> >>>> >> 2. Set the url to ".", skip the commit and specify a subdir
>>>> relative
>>>> >>>> to
>>>> >>>> >> the root of the repo. Plugman then runs git-rev parse to find
>>>> the
>>>> >>>> root and
>>>> >>>> >> install from there.
>>>> >>>> >>
>>>> >>>> >> I would like to propose a third way which would be relative to
>>>> the
>>>> >>>> >> current install and not use git at all
>>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir relative
>>>> to the
>>>> >>>> >> current plugin.xml.
>>>> >>>> >>
>>>> >>>> >> This would allow us to distribute a version of cordova with
>>>> plugins
>>>> >>>> to
>>>> >>>> >> anyone without an unnecessary requirement on git (considering
>>>> the
>>>> >>>> plugins
>>>> >>>> >> are fully installed)
>>>> >>>> >>
>>>> >>>> >>
>>>> >>>> >>
>>>> >>>> >> 1.
>>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>> >>>> >>
>>>> >>>> >>
>>>> ---------------------------------------------------------------------
>>>> >>>> >> This transmission (including any attachments) may contain
>>>> >>>> confidential
>>>> >>>> >> information, privileged material (including material protected
>>>> by the
>>>> >>>> >> solicitor-client or other applicable privileges), or constitute
>>>> >>>> non-public
>>>> >>>> >> information. Any use of this information by anyone other than
>>>> the
>>>> >>>> intended
>>>> >>>> >> recipient is prohibited. If you have received this transmission
>>>> in
>>>> >>>> error,
>>>> >>>> >> please immediately reply to the sender and delete this
>>>> information
>>>> >>>> from
>>>> >>>> >> your system. Use, dissemination, distribution, or reproduction
>>>> of
>>>> >>>> this
>>>> >>>> >> transmission by unintended recipients is not authorized and may
>>>> be
>>>> >>>> unlawful.
>>>> >>>> >>
>>>> >>>> >
>>>> >>>> >
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Michal Mocny <mm...@chromium.org>.
.. but either way if we add support for filesystem-relative paths and they
work when fetching the original plugin either from git or locally, then we
are done.

As an aside, when a plugin lists its dependency as explicitly from a git
url, can the user somehow override that to install from a local copy?
 Perhaps if they manually install the dependant first, then we won't go
fetch from git needlessly?  How does that interact with different versions
of the plugin?

-Michal


On Wed, Sep 4, 2013 at 11:15 AM, Michal Mocny <mm...@chromium.org> wrote:

> Jeffrey's point at the start of this thread is that he isn't using a git
> repo locally, so there is no .git folder to find.
>
>
> On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> I like where this is generally going, but I want to correct one mistake
>> Michal made. There /is/ a way to know which directory above a plugin is the
>> root. The code uses git to find the .git directory, which is taken to be
>> the root from which the subdir is relative. That means that in the case of
>> url="." and url="https://github.com/..." the subdir has the same
>> meaning: relative to the git root.
>>
>> I like the path="" option. I agree that subdir and ref could be dropped,
>> since they can be specified as part of the URL. On the other hand, there's
>> no harm in keeping them around for compatibility.
>>
>> I suggest:
>>
>> 1. Remote git, all in URL: url="
>> https://github.com/foo/bar.git#somebranch:sub/dir"
>>  2. Remote git, separate parameters: url="https://github.com/foo/bar.git"
>> subdir="sub/dir" ref="somebranch"
>> 3. Local, git-root-relative: url="." subdir="sub/dir" ref="somebranch"
>>    (we can probably support all-in-URL here too)
>> 4. Local, filesystem-relative: url="../../sub/dir"      (no all-in-URL
>> here; there's no need for the other parameters in this case)
>>
>> The last can be differentiated from the others easily enough, the logic
>> is:
>> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a remote git.
>> This is already supported fully.
>> 2. Is the url === "."? If so, it's a local git-relative path. Already
>> fully supported.
>> 3. Otherwise, it's a filesystem-relative path, and so the new plugin can
>> be found at path.resolve(path_to_current_plugin, dep.attrib.url); Though
>> some path-separator tweaking is always required.
>>
>> (Re: paths, all paths in plugin.xml should be specified to use / always,
>> URLs and filesystem paths both. It's the tool's job to properly split and
>> convert to Windows backslashes where appropriate. I'm sure there are a few
>> places where we've gotten this wrong; Windows users please file bugs if you
>> run into them. Mostly, though, I was careful to split/join explicitly on /
>> or use path.foo functions appropriately.)
>>
>> Thoughts on that proposal?
>>
>> Braden
>>
>>
>> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org>wrote:
>>
>>> For now, yes, but we could extend that without breaking anything, no?
>>>  Right now url="../etc" would be invalid, so we could safely add support
>>> for urls with leading "..", and make that relative to current plugin.
>>>
>>> url="." would still do what it does today, but could likely be deprecated
>>> along with subdir and commit attributes (or at least document the
>>> limitation of that approach somewhere).
>>>
>>> Not sure about making the form url="./etc" be relative to URL root or
>>> current plugin, but I don't see why that form would ever be useful
>>> anyway.
>>>
>>> -Michal
>>>
>>>
>>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
>>> wrote:
>>>
>>> > Because for the hosted case, the URL points to where the repo is, not
>>> to
>>> > where the plugin is.
>>> >
>>> >
>>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>> >
>>> >> If URL can be relative, why do we need a new path parameter?  All we
>>> >> would need is to treat leading ./ or ../ as relative to the plugin not
>>> >> root, which I think is fine.
>>> >>
>>> >> I'll sleep on it and draw it out on whiteboard tomorrow to make sure
>>> all
>>> >> the cases are handled.
>>> >>
>>> >>
>>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <agrieve@chromium.org
>>> >wrote:
>>> >>
>>> >>> Agree the use-case is valid. Here's a variation on (1) that I think
>>> is
>>> >>> marginally nicer:
>>> >>>
>>> >>> url="." to be made optional, but default value is "."
>>> >>> subdir="" works only with git repos and is always relative to the
>>> root
>>> >>> of the repo.
>>> >>> path="" works with git repos or local paths and is relative to the
>>> >>> plugin.xml of the current plugin. You can't have "url" or "subdir"
>>> if you
>>> >>> have "path".
>>> >>>
>>> >>> Support was just added for specifying commit and path within url.
>>> So, we
>>> >>> could actually just deprecate "subdir". and have "url" or "path"
>>> >>>
>>> >>> E.g.: url="some/path.git" would specify a git URL relative to the
>>> >>> current plugin's git url.
>>> >>> E.g.: url="#branch2" would specify a branch on the current URL
>>> >>> (cordova-labs style)
>>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the current
>>> URL
>>> >>> plus a subdir within it.
>>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just want
>>> to
>>> >>> set the path)
>>> >>> E.g.: path="../B" is always a relative fs path. If the current
>>> plugin is
>>> >>> from git, then be careful not to go above the git root.
>>> >>>
>>> >>>
>>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mmocny@chromium.org
>>> >wrote:
>>> >>>
>>> >>>> Mulling this over a bit, I think I would like a solution for
>>> specifying
>>> >>>> dependancies that would work regardless of where/how the plugins are
>>> >>>> hosted, git or local.  If you had:
>>> >>>>
>>> >>>> BB_PLUGINS/
>>> >>>> - plug1/
>>> >>>> - plug2/
>>> >>>> ...
>>> >>>>
>>> >>>> (and plug1 depends on plug2), then:
>>> >>>>
>>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..
>>> cordova
>>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>> >>>>
>>> >>>> ..should both work without changing all of the dependency tags in
>>> plug1.
>>> >>>>  Actually, the plugin author should not have an explicit say in how
>>> a
>>> >>>> user
>>> >>>> manages these directories (except in the directory structure).  Note
>>> >>>> that
>>> >>>> this situation applies whenever a user clones your plugin repo to
>>> >>>> locally,
>>> >>>> or for the reverse direction, when ever they add your plugins into
>>> their
>>> >>>> teams' git repo.
>>> >>>>
>>> >>>>
>>> >>>> Right now, thats not possible, because when installing from local
>>> path
>>> >>>> with
>>> >>>> url="." there is no way to know which of the plugins parent
>>> directories
>>> >>>> to
>>> >>>> consider as the "root".  We could resolve this using several ways,
>>> among
>>> >>>> them:
>>> >>>>
>>> >>>> (1) Jeffreys proposal: dropping the url="." means "path relative to
>>> this
>>> >>>> plugin" (note however, that I propose it also works when installing
>>> >>>> from a
>>> >>>> git repo).  Deprecate/warn against using url=".".
>>> >>>>
>>> >>>> (2) Support a new special file to "mark" the plugin root dir so we
>>> can
>>> >>>> walk
>>> >>>> the directory tree to find the valid target for url="." (ie,
>>> replace the
>>> >>>> requirement for a .git with a requirement for a .cordova_repo,
>>> which BB
>>> >>>> and
>>> >>>> others could place within their plugin bundle).
>>> >>>>
>>> >>>>
>>> >>>> I like (1).
>>> >>>>
>>> >>>> -Michal
>>> >>>>
>>> >>>>
>>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org>
>>> >>>> wrote:
>>> >>>>
>>> >>>> > Sounds reasonable to me.
>>> >>>> >
>>> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do
>>> what
>>> >>>> you
>>> >>>> > request when the url for the original plugin was a local path?
>>>  Maybe
>>> >>>> just
>>> >>>> > a bug?
>>> >>>> >
>>> >>>> > -Michal
>>> >>>> >
>>> >>>> >
>>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>> >>>> jheifetz@blackberry.com>wrote:
>>> >>>> >
>>> >>>> >> We were working on a redistribution of Cordova that included some
>>> >>>> plugins
>>> >>>> >> and ran into a use-case not covered by the current plugin
>>> spec.[1]
>>> >>>> >>
>>> >>>> >> Currently there are two ways to specify a dependency
>>> >>>> >> 1. Using a combination of url, commit and subdir which plugman
>>> will
>>> >>>> use
>>> >>>> >> to clone down a repo and install
>>> >>>> >> 2. Set the url to ".", skip the commit and specify a subdir
>>> relative
>>> >>>> to
>>> >>>> >> the root of the repo. Plugman then runs git-rev parse to find the
>>> >>>> root and
>>> >>>> >> install from there.
>>> >>>> >>
>>> >>>> >> I would like to propose a third way which would be relative to
>>> the
>>> >>>> >> current install and not use git at all
>>> >>>> >> 3. Skip the url, skip the commit and specify a subdir relative
>>> to the
>>> >>>> >> current plugin.xml.
>>> >>>> >>
>>> >>>> >> This would allow us to distribute a version of cordova with
>>> plugins
>>> >>>> to
>>> >>>> >> anyone without an unnecessary requirement on git (considering the
>>> >>>> plugins
>>> >>>> >> are fully installed)
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> 1.
>>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>> >>>> >>
>>> >>>> >>
>>> ---------------------------------------------------------------------
>>> >>>> >> This transmission (including any attachments) may contain
>>> >>>> confidential
>>> >>>> >> information, privileged material (including material protected
>>> by the
>>> >>>> >> solicitor-client or other applicable privileges), or constitute
>>> >>>> non-public
>>> >>>> >> information. Any use of this information by anyone other than the
>>> >>>> intended
>>> >>>> >> recipient is prohibited. If you have received this transmission
>>> in
>>> >>>> error,
>>> >>>> >> please immediately reply to the sender and delete this
>>> information
>>> >>>> from
>>> >>>> >> your system. Use, dissemination, distribution, or reproduction of
>>> >>>> this
>>> >>>> >> transmission by unintended recipients is not authorized and may
>>> be
>>> >>>> unlawful.
>>> >>>> >>
>>> >>>> >
>>> >>>> >
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Michal Mocny <mm...@chromium.org>.
Jeffrey's point at the start of this thread is that he isn't using a git
repo locally, so there is no .git folder to find.


On Wed, Sep 4, 2013 at 10:38 AM, Braden Shepherdson <br...@chromium.org>wrote:

> I like where this is generally going, but I want to correct one mistake
> Michal made. There /is/ a way to know which directory above a plugin is the
> root. The code uses git to find the .git directory, which is taken to be
> the root from which the subdir is relative. That means that in the case of
> url="." and url="https://github.com/..." the subdir has the same meaning:
> relative to the git root.
>
> I like the path="" option. I agree that subdir and ref could be dropped,
> since they can be specified as part of the URL. On the other hand, there's
> no harm in keeping them around for compatibility.
>
> I suggest:
>
> 1. Remote git, all in URL: url="
> https://github.com/foo/bar.git#somebranch:sub/dir"
>  2. Remote git, separate parameters: url="https://github.com/foo/bar.git"
> subdir="sub/dir" ref="somebranch"
> 3. Local, git-root-relative: url="." subdir="sub/dir" ref="somebranch"
>  (we can probably support all-in-URL here too)
> 4. Local, filesystem-relative: url="../../sub/dir"      (no all-in-URL
> here; there's no need for the other parameters in this case)
>
> The last can be differentiated from the others easily enough, the logic is:
> 1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a remote git.
> This is already supported fully.
> 2. Is the url === "."? If so, it's a local git-relative path. Already
> fully supported.
> 3. Otherwise, it's a filesystem-relative path, and so the new plugin can
> be found at path.resolve(path_to_current_plugin, dep.attrib.url); Though
> some path-separator tweaking is always required.
>
> (Re: paths, all paths in plugin.xml should be specified to use / always,
> URLs and filesystem paths both. It's the tool's job to properly split and
> convert to Windows backslashes where appropriate. I'm sure there are a few
> places where we've gotten this wrong; Windows users please file bugs if you
> run into them. Mostly, though, I was careful to split/join explicitly on /
> or use path.foo functions appropriately.)
>
> Thoughts on that proposal?
>
> Braden
>
>
> On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org> wrote:
>
>> For now, yes, but we could extend that without breaking anything, no?
>>  Right now url="../etc" would be invalid, so we could safely add support
>> for urls with leading "..", and make that relative to current plugin.
>>
>> url="." would still do what it does today, but could likely be deprecated
>> along with subdir and commit attributes (or at least document the
>> limitation of that approach somewhere).
>>
>> Not sure about making the form url="./etc" be relative to URL root or
>> current plugin, but I don't see why that form would ever be useful anyway.
>>
>> -Michal
>>
>>
>> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
>> wrote:
>>
>> > Because for the hosted case, the URL points to where the repo is, not to
>> > where the plugin is.
>> >
>> >
>> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org>
>> wrote:
>> >
>> >> If URL can be relative, why do we need a new path parameter?  All we
>> >> would need is to treat leading ./ or ../ as relative to the plugin not
>> >> root, which I think is fine.
>> >>
>> >> I'll sleep on it and draw it out on whiteboard tomorrow to make sure
>> all
>> >> the cases are handled.
>> >>
>> >>
>> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <agrieve@chromium.org
>> >wrote:
>> >>
>> >>> Agree the use-case is valid. Here's a variation on (1) that I think is
>> >>> marginally nicer:
>> >>>
>> >>> url="." to be made optional, but default value is "."
>> >>> subdir="" works only with git repos and is always relative to the root
>> >>> of the repo.
>> >>> path="" works with git repos or local paths and is relative to the
>> >>> plugin.xml of the current plugin. You can't have "url" or "subdir" if
>> you
>> >>> have "path".
>> >>>
>> >>> Support was just added for specifying commit and path within url. So,
>> we
>> >>> could actually just deprecate "subdir". and have "url" or "path"
>> >>>
>> >>> E.g.: url="some/path.git" would specify a git URL relative to the
>> >>> current plugin's git url.
>> >>> E.g.: url="#branch2" would specify a branch on the current URL
>> >>> (cordova-labs style)
>> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the current
>> URL
>> >>> plus a subdir within it.
>> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just want
>> to
>> >>> set the path)
>> >>> E.g.: path="../B" is always a relative fs path. If the current plugin
>> is
>> >>> from git, then be careful not to go above the git root.
>> >>>
>> >>>
>> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mmocny@chromium.org
>> >wrote:
>> >>>
>> >>>> Mulling this over a bit, I think I would like a solution for
>> specifying
>> >>>> dependancies that would work regardless of where/how the plugins are
>> >>>> hosted, git or local.  If you had:
>> >>>>
>> >>>> BB_PLUGINS/
>> >>>> - plug1/
>> >>>> - plug2/
>> >>>> ...
>> >>>>
>> >>>> (and plug1 depends on plug2), then:
>> >>>>
>> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..
>> cordova
>> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>> >>>>
>> >>>> ..should both work without changing all of the dependency tags in
>> plug1.
>> >>>>  Actually, the plugin author should not have an explicit say in how a
>> >>>> user
>> >>>> manages these directories (except in the directory structure).  Note
>> >>>> that
>> >>>> this situation applies whenever a user clones your plugin repo to
>> >>>> locally,
>> >>>> or for the reverse direction, when ever they add your plugins into
>> their
>> >>>> teams' git repo.
>> >>>>
>> >>>>
>> >>>> Right now, thats not possible, because when installing from local
>> path
>> >>>> with
>> >>>> url="." there is no way to know which of the plugins parent
>> directories
>> >>>> to
>> >>>> consider as the "root".  We could resolve this using several ways,
>> among
>> >>>> them:
>> >>>>
>> >>>> (1) Jeffreys proposal: dropping the url="." means "path relative to
>> this
>> >>>> plugin" (note however, that I propose it also works when installing
>> >>>> from a
>> >>>> git repo).  Deprecate/warn against using url=".".
>> >>>>
>> >>>> (2) Support a new special file to "mark" the plugin root dir so we
>> can
>> >>>> walk
>> >>>> the directory tree to find the valid target for url="." (ie, replace
>> the
>> >>>> requirement for a .git with a requirement for a .cordova_repo, which
>> BB
>> >>>> and
>> >>>> others could place within their plugin bundle).
>> >>>>
>> >>>>
>> >>>> I like (1).
>> >>>>
>> >>>> -Michal
>> >>>>
>> >>>>
>> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org>
>> >>>> wrote:
>> >>>>
>> >>>> > Sounds reasonable to me.
>> >>>> >
>> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do what
>> >>>> you
>> >>>> > request when the url for the original plugin was a local path?
>>  Maybe
>> >>>> just
>> >>>> > a bug?
>> >>>> >
>> >>>> > -Michal
>> >>>> >
>> >>>> >
>> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>> >>>> jheifetz@blackberry.com>wrote:
>> >>>> >
>> >>>> >> We were working on a redistribution of Cordova that included some
>> >>>> plugins
>> >>>> >> and ran into a use-case not covered by the current plugin spec.[1]
>> >>>> >>
>> >>>> >> Currently there are two ways to specify a dependency
>> >>>> >> 1. Using a combination of url, commit and subdir which plugman
>> will
>> >>>> use
>> >>>> >> to clone down a repo and install
>> >>>> >> 2. Set the url to ".", skip the commit and specify a subdir
>> relative
>> >>>> to
>> >>>> >> the root of the repo. Plugman then runs git-rev parse to find the
>> >>>> root and
>> >>>> >> install from there.
>> >>>> >>
>> >>>> >> I would like to propose a third way which would be relative to the
>> >>>> >> current install and not use git at all
>> >>>> >> 3. Skip the url, skip the commit and specify a subdir relative to
>> the
>> >>>> >> current plugin.xml.
>> >>>> >>
>> >>>> >> This would allow us to distribute a version of cordova with
>> plugins
>> >>>> to
>> >>>> >> anyone without an unnecessary requirement on git (considering the
>> >>>> plugins
>> >>>> >> are fully installed)
>> >>>> >>
>> >>>> >>
>> >>>> >>
>> >>>> >> 1.
>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>> >>>> >>
>> >>>> >>
>> ---------------------------------------------------------------------
>> >>>> >> This transmission (including any attachments) may contain
>> >>>> confidential
>> >>>> >> information, privileged material (including material protected by
>> the
>> >>>> >> solicitor-client or other applicable privileges), or constitute
>> >>>> non-public
>> >>>> >> information. Any use of this information by anyone other than the
>> >>>> intended
>> >>>> >> recipient is prohibited. If you have received this transmission in
>> >>>> error,
>> >>>> >> please immediately reply to the sender and delete this information
>> >>>> from
>> >>>> >> your system. Use, dissemination, distribution, or reproduction of
>> >>>> this
>> >>>> >> transmission by unintended recipients is not authorized and may be
>> >>>> unlawful.
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>>
>
>

Re: Non-Git Plugin Dependencies

Posted by Braden Shepherdson <br...@chromium.org>.
I like where this is generally going, but I want to correct one mistake
Michal made. There /is/ a way to know which directory above a plugin is the
root. The code uses git to find the .git directory, which is taken to be
the root from which the subdir is relative. That means that in the case of
url="." and url="https://github.com/..." the subdir has the same meaning:
relative to the git root.

I like the path="" option. I agree that subdir and ref could be dropped,
since they can be specified as part of the URL. On the other hand, there's
no harm in keeping them around for compatibility.

I suggest:

1. Remote git, all in URL: url="
https://github.com/foo/bar.git#somebranch:sub/dir"
2. Remote git, separate parameters: url="https://github.com/foo/bar.git"
subdir="sub/dir" ref="somebranch"
3. Local, git-root-relative: url="." subdir="sub/dir" ref="somebranch"
 (we can probably support all-in-URL here too)
4. Local, filesystem-relative: url="../../sub/dir"      (no all-in-URL
here; there's no need for the other parameters in this case)

The last can be differentiated from the others easily enough, the logic is:
1. Is it a valid URL? (ie. indexOf('://') >= 0) If so, it's a remote git.
This is already supported fully.
2. Is the url === "."? If so, it's a local git-relative path. Already fully
supported.
3. Otherwise, it's a filesystem-relative path, and so the new plugin can be
found at path.resolve(path_to_current_plugin, dep.attrib.url); Though some
path-separator tweaking is always required.

(Re: paths, all paths in plugin.xml should be specified to use / always,
URLs and filesystem paths both. It's the tool's job to properly split and
convert to Windows backslashes where appropriate. I'm sure there are a few
places where we've gotten this wrong; Windows users please file bugs if you
run into them. Mostly, though, I was careful to split/join explicitly on /
or use path.foo functions appropriately.)

Thoughts on that proposal?

Braden


On Wed, Sep 4, 2013 at 10:09 AM, Michal Mocny <mm...@chromium.org> wrote:

> For now, yes, but we could extend that without breaking anything, no?
>  Right now url="../etc" would be invalid, so we could safely add support
> for urls with leading "..", and make that relative to current plugin.
>
> url="." would still do what it does today, but could likely be deprecated
> along with subdir and commit attributes (or at least document the
> limitation of that approach somewhere).
>
> Not sure about making the form url="./etc" be relative to URL root or
> current plugin, but I don't see why that form would ever be useful anyway.
>
> -Michal
>
>
> On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Because for the hosted case, the URL points to where the repo is, not to
> > where the plugin is.
> >
> >
> > On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> >> If URL can be relative, why do we need a new path parameter?  All we
> >> would need is to treat leading ./ or ../ as relative to the plugin not
> >> root, which I think is fine.
> >>
> >> I'll sleep on it and draw it out on whiteboard tomorrow to make sure all
> >> the cases are handled.
> >>
> >>
> >> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
> >>
> >>> Agree the use-case is valid. Here's a variation on (1) that I think is
> >>> marginally nicer:
> >>>
> >>> url="." to be made optional, but default value is "."
> >>> subdir="" works only with git repos and is always relative to the root
> >>> of the repo.
> >>> path="" works with git repos or local paths and is relative to the
> >>> plugin.xml of the current plugin. You can't have "url" or "subdir" if
> you
> >>> have "path".
> >>>
> >>> Support was just added for specifying commit and path within url. So,
> we
> >>> could actually just deprecate "subdir". and have "url" or "path"
> >>>
> >>> E.g.: url="some/path.git" would specify a git URL relative to the
> >>> current plugin's git url.
> >>> E.g.: url="#branch2" would specify a branch on the current URL
> >>> (cordova-labs style)
> >>> E.g.: url="#branch2:plugins/A" would specify a branch on the current
> URL
> >>> plus a subdir within it.
> >>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just want to
> >>> set the path)
> >>> E.g.: path="../B" is always a relative fs path. If the current plugin
> is
> >>> from git, then be careful not to go above the git root.
> >>>
> >>>
> >>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mmocny@chromium.org
> >wrote:
> >>>
> >>>> Mulling this over a bit, I think I would like a solution for
> specifying
> >>>> dependancies that would work regardless of where/how the plugins are
> >>>> hosted, git or local.  If you had:
> >>>>
> >>>> BB_PLUGINS/
> >>>> - plug1/
> >>>> - plug2/
> >>>> ...
> >>>>
> >>>> (and plug1 depends on plug2), then:
> >>>>
> >>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..   cordova
> >>>> plugin add GIT_REPO:BB_PLUGINS/plug1
> >>>>
> >>>> ..should both work without changing all of the dependency tags in
> plug1.
> >>>>  Actually, the plugin author should not have an explicit say in how a
> >>>> user
> >>>> manages these directories (except in the directory structure).  Note
> >>>> that
> >>>> this situation applies whenever a user clones your plugin repo to
> >>>> locally,
> >>>> or for the reverse direction, when ever they add your plugins into
> their
> >>>> teams' git repo.
> >>>>
> >>>>
> >>>> Right now, thats not possible, because when installing from local path
> >>>> with
> >>>> url="." there is no way to know which of the plugins parent
> directories
> >>>> to
> >>>> consider as the "root".  We could resolve this using several ways,
> among
> >>>> them:
> >>>>
> >>>> (1) Jeffreys proposal: dropping the url="." means "path relative to
> this
> >>>> plugin" (note however, that I propose it also works when installing
> >>>> from a
> >>>> git repo).  Deprecate/warn against using url=".".
> >>>>
> >>>> (2) Support a new special file to "mark" the plugin root dir so we can
> >>>> walk
> >>>> the directory tree to find the valid target for url="." (ie, replace
> the
> >>>> requirement for a .git with a requirement for a .cordova_repo, which
> BB
> >>>> and
> >>>> others could place within their plugin bundle).
> >>>>
> >>>>
> >>>> I like (1).
> >>>>
> >>>> -Michal
> >>>>
> >>>>
> >>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org>
> >>>> wrote:
> >>>>
> >>>> > Sounds reasonable to me.
> >>>> >
> >>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do what
> >>>> you
> >>>> > request when the url for the original plugin was a local path?
>  Maybe
> >>>> just
> >>>> > a bug?
> >>>> >
> >>>> > -Michal
> >>>> >
> >>>> >
> >>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
> >>>> jheifetz@blackberry.com>wrote:
> >>>> >
> >>>> >> We were working on a redistribution of Cordova that included some
> >>>> plugins
> >>>> >> and ran into a use-case not covered by the current plugin spec.[1]
> >>>> >>
> >>>> >> Currently there are two ways to specify a dependency
> >>>> >> 1. Using a combination of url, commit and subdir which plugman will
> >>>> use
> >>>> >> to clone down a repo and install
> >>>> >> 2. Set the url to ".", skip the commit and specify a subdir
> relative
> >>>> to
> >>>> >> the root of the repo. Plugman then runs git-rev parse to find the
> >>>> root and
> >>>> >> install from there.
> >>>> >>
> >>>> >> I would like to propose a third way which would be relative to the
> >>>> >> current install and not use git at all
> >>>> >> 3. Skip the url, skip the commit and specify a subdir relative to
> the
> >>>> >> current plugin.xml.
> >>>> >>
> >>>> >> This would allow us to distribute a version of cordova with plugins
> >>>> to
> >>>> >> anyone without an unnecessary requirement on git (considering the
> >>>> plugins
> >>>> >> are fully installed)
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
> >>>> >>
> >>>> >>
> ---------------------------------------------------------------------
> >>>> >> This transmission (including any attachments) may contain
> >>>> confidential
> >>>> >> information, privileged material (including material protected by
> the
> >>>> >> solicitor-client or other applicable privileges), or constitute
> >>>> non-public
> >>>> >> information. Any use of this information by anyone other than the
> >>>> intended
> >>>> >> recipient is prohibited. If you have received this transmission in
> >>>> error,
> >>>> >> please immediately reply to the sender and delete this information
> >>>> from
> >>>> >> your system. Use, dissemination, distribution, or reproduction of
> >>>> this
> >>>> >> transmission by unintended recipients is not authorized and may be
> >>>> unlawful.
> >>>> >>
> >>>> >
> >>>> >
> >>>>
> >>>
> >>>
> >>
> >
>

Re: Non-Git Plugin Dependencies

Posted by Michal Mocny <mm...@chromium.org>.
For now, yes, but we could extend that without breaking anything, no?
 Right now url="../etc" would be invalid, so we could safely add support
for urls with leading "..", and make that relative to current plugin.

url="." would still do what it does today, but could likely be deprecated
along with subdir and commit attributes (or at least document the
limitation of that approach somewhere).

Not sure about making the form url="./etc" be relative to URL root or
current plugin, but I don't see why that form would ever be useful anyway.

-Michal


On Wed, Sep 4, 2013 at 9:21 AM, Andrew Grieve <ag...@chromium.org> wrote:

> Because for the hosted case, the URL points to where the repo is, not to
> where the plugin is.
>
>
> On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org> wrote:
>
>> If URL can be relative, why do we need a new path parameter?  All we
>> would need is to treat leading ./ or ../ as relative to the plugin not
>> root, which I think is fine.
>>
>> I'll sleep on it and draw it out on whiteboard tomorrow to make sure all
>> the cases are handled.
>>
>>
>> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>
>>> Agree the use-case is valid. Here's a variation on (1) that I think is
>>> marginally nicer:
>>>
>>> url="." to be made optional, but default value is "."
>>> subdir="" works only with git repos and is always relative to the root
>>> of the repo.
>>> path="" works with git repos or local paths and is relative to the
>>> plugin.xml of the current plugin. You can't have "url" or "subdir" if you
>>> have "path".
>>>
>>> Support was just added for specifying commit and path within url. So, we
>>> could actually just deprecate "subdir". and have "url" or "path"
>>>
>>> E.g.: url="some/path.git" would specify a git URL relative to the
>>> current plugin's git url.
>>> E.g.: url="#branch2" would specify a branch on the current URL
>>> (cordova-labs style)
>>> E.g.: url="#branch2:plugins/A" would specify a branch on the current URL
>>> plus a subdir within it.
>>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just want to
>>> set the path)
>>> E.g.: path="../B" is always a relative fs path. If the current plugin is
>>> from git, then be careful not to go above the git root.
>>>
>>>
>>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mm...@chromium.org>wrote:
>>>
>>>> Mulling this over a bit, I think I would like a solution for specifying
>>>> dependancies that would work regardless of where/how the plugins are
>>>> hosted, git or local.  If you had:
>>>>
>>>> BB_PLUGINS/
>>>> - plug1/
>>>> - plug2/
>>>> ...
>>>>
>>>> (and plug1 depends on plug2), then:
>>>>
>>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..   cordova
>>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>>
>>>> ..should both work without changing all of the dependency tags in plug1.
>>>>  Actually, the plugin author should not have an explicit say in how a
>>>> user
>>>> manages these directories (except in the directory structure).  Note
>>>> that
>>>> this situation applies whenever a user clones your plugin repo to
>>>> locally,
>>>> or for the reverse direction, when ever they add your plugins into their
>>>> teams' git repo.
>>>>
>>>>
>>>> Right now, thats not possible, because when installing from local path
>>>> with
>>>> url="." there is no way to know which of the plugins parent directories
>>>> to
>>>> consider as the "root".  We could resolve this using several ways, among
>>>> them:
>>>>
>>>> (1) Jeffreys proposal: dropping the url="." means "path relative to this
>>>> plugin" (note however, that I propose it also works when installing
>>>> from a
>>>> git repo).  Deprecate/warn against using url=".".
>>>>
>>>> (2) Support a new special file to "mark" the plugin root dir so we can
>>>> walk
>>>> the directory tree to find the valid target for url="." (ie, replace the
>>>> requirement for a .git with a requirement for a .cordova_repo, which BB
>>>> and
>>>> others could place within their plugin bundle).
>>>>
>>>>
>>>> I like (1).
>>>>
>>>> -Michal
>>>>
>>>>
>>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org>
>>>> wrote:
>>>>
>>>> > Sounds reasonable to me.
>>>> >
>>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do what
>>>> you
>>>> > request when the url for the original plugin was a local path?  Maybe
>>>> just
>>>> > a bug?
>>>> >
>>>> > -Michal
>>>> >
>>>> >
>>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>>> jheifetz@blackberry.com>wrote:
>>>> >
>>>> >> We were working on a redistribution of Cordova that included some
>>>> plugins
>>>> >> and ran into a use-case not covered by the current plugin spec.[1]
>>>> >>
>>>> >> Currently there are two ways to specify a dependency
>>>> >> 1. Using a combination of url, commit and subdir which plugman will
>>>> use
>>>> >> to clone down a repo and install
>>>> >> 2. Set the url to ".", skip the commit and specify a subdir relative
>>>> to
>>>> >> the root of the repo. Plugman then runs git-rev parse to find the
>>>> root and
>>>> >> install from there.
>>>> >>
>>>> >> I would like to propose a third way which would be relative to the
>>>> >> current install and not use git at all
>>>> >> 3. Skip the url, skip the commit and specify a subdir relative to the
>>>> >> current plugin.xml.
>>>> >>
>>>> >> This would allow us to distribute a version of cordova with plugins
>>>> to
>>>> >> anyone without an unnecessary requirement on git (considering the
>>>> plugins
>>>> >> are fully installed)
>>>> >>
>>>> >>
>>>> >>
>>>> >> 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> This transmission (including any attachments) may contain
>>>> confidential
>>>> >> information, privileged material (including material protected by the
>>>> >> solicitor-client or other applicable privileges), or constitute
>>>> non-public
>>>> >> information. Any use of this information by anyone other than the
>>>> intended
>>>> >> recipient is prohibited. If you have received this transmission in
>>>> error,
>>>> >> please immediately reply to the sender and delete this information
>>>> from
>>>> >> your system. Use, dissemination, distribution, or reproduction of
>>>> this
>>>> >> transmission by unintended recipients is not authorized and may be
>>>> unlawful.
>>>> >>
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Andrew Grieve <ag...@chromium.org>.
Because for the hosted case, the URL points to where the repo is, not to
where the plugin is.


On Wed, Sep 4, 2013 at 12:15 AM, Michal Mocny <mm...@chromium.org> wrote:

> If URL can be relative, why do we need a new path parameter?  All we would
> need is to treat leading ./ or ../ as relative to the plugin not root,
> which I think is fine.
>
> I'll sleep on it and draw it out on whiteboard tomorrow to make sure all
> the cases are handled.
>
>
> On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> Agree the use-case is valid. Here's a variation on (1) that I think is
>> marginally nicer:
>>
>> url="." to be made optional, but default value is "."
>> subdir="" works only with git repos and is always relative to the root of
>> the repo.
>> path="" works with git repos or local paths and is relative to the
>> plugin.xml of the current plugin. You can't have "url" or "subdir" if you
>> have "path".
>>
>> Support was just added for specifying commit and path within url. So, we
>> could actually just deprecate "subdir". and have "url" or "path"
>>
>> E.g.: url="some/path.git" would specify a git URL relative to the current
>> plugin's git url.
>> E.g.: url="#branch2" would specify a branch on the current URL
>> (cordova-labs style)
>> E.g.: url="#branch2:plugins/A" would specify a branch on the current URL
>> plus a subdir within it.
>> E.g.: url="#:plugins/A" would be invalid. (Use path if you just want to
>> set the path)
>> E.g.: path="../B" is always a relative fs path. If the current plugin is
>> from git, then be careful not to go above the git root.
>>
>>
>> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mm...@chromium.org>wrote:
>>
>>> Mulling this over a bit, I think I would like a solution for specifying
>>> dependancies that would work regardless of where/how the plugins are
>>> hosted, git or local.  If you had:
>>>
>>> BB_PLUGINS/
>>> - plug1/
>>> - plug2/
>>> ...
>>>
>>> (and plug1 depends on plug2), then:
>>>
>>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..   cordova
>>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>>
>>> ..should both work without changing all of the dependency tags in plug1.
>>>  Actually, the plugin author should not have an explicit say in how a
>>> user
>>> manages these directories (except in the directory structure).  Note that
>>> this situation applies whenever a user clones your plugin repo to
>>> locally,
>>> or for the reverse direction, when ever they add your plugins into their
>>> teams' git repo.
>>>
>>>
>>> Right now, thats not possible, because when installing from local path
>>> with
>>> url="." there is no way to know which of the plugins parent directories
>>> to
>>> consider as the "root".  We could resolve this using several ways, among
>>> them:
>>>
>>> (1) Jeffreys proposal: dropping the url="." means "path relative to this
>>> plugin" (note however, that I propose it also works when installing from
>>> a
>>> git repo).  Deprecate/warn against using url=".".
>>>
>>> (2) Support a new special file to "mark" the plugin root dir so we can
>>> walk
>>> the directory tree to find the valid target for url="." (ie, replace the
>>> requirement for a .git with a requirement for a .cordova_repo, which BB
>>> and
>>> others could place within their plugin bundle).
>>>
>>>
>>> I like (1).
>>>
>>> -Michal
>>>
>>>
>>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>>
>>> > Sounds reasonable to me.
>>> >
>>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do what you
>>> > request when the url for the original plugin was a local path?  Maybe
>>> just
>>> > a bug?
>>> >
>>> > -Michal
>>> >
>>> >
>>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>>> jheifetz@blackberry.com>wrote:
>>> >
>>> >> We were working on a redistribution of Cordova that included some
>>> plugins
>>> >> and ran into a use-case not covered by the current plugin spec.[1]
>>> >>
>>> >> Currently there are two ways to specify a dependency
>>> >> 1. Using a combination of url, commit and subdir which plugman will
>>> use
>>> >> to clone down a repo and install
>>> >> 2. Set the url to ".", skip the commit and specify a subdir relative
>>> to
>>> >> the root of the repo. Plugman then runs git-rev parse to find the
>>> root and
>>> >> install from there.
>>> >>
>>> >> I would like to propose a third way which would be relative to the
>>> >> current install and not use git at all
>>> >> 3. Skip the url, skip the commit and specify a subdir relative to the
>>> >> current plugin.xml.
>>> >>
>>> >> This would allow us to distribute a version of cordova with plugins to
>>> >> anyone without an unnecessary requirement on git (considering the
>>> plugins
>>> >> are fully installed)
>>> >>
>>> >>
>>> >>
>>> >> 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> This transmission (including any attachments) may contain confidential
>>> >> information, privileged material (including material protected by the
>>> >> solicitor-client or other applicable privileges), or constitute
>>> non-public
>>> >> information. Any use of this information by anyone other than the
>>> intended
>>> >> recipient is prohibited. If you have received this transmission in
>>> error,
>>> >> please immediately reply to the sender and delete this information
>>> from
>>> >> your system. Use, dissemination, distribution, or reproduction of this
>>> >> transmission by unintended recipients is not authorized and may be
>>> unlawful.
>>> >>
>>> >
>>> >
>>>
>>
>>
>

Re: Non-Git Plugin Dependencies

Posted by Michal Mocny <mm...@chromium.org>.
If URL can be relative, why do we need a new path parameter?  All we would
need is to treat leading ./ or ../ as relative to the plugin not root,
which I think is fine.

I'll sleep on it and draw it out on whiteboard tomorrow to make sure all
the cases are handled.


On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Agree the use-case is valid. Here's a variation on (1) that I think is
> marginally nicer:
>
> url="." to be made optional, but default value is "."
> subdir="" works only with git repos and is always relative to the root of
> the repo.
> path="" works with git repos or local paths and is relative to the
> plugin.xml of the current plugin. You can't have "url" or "subdir" if you
> have "path".
>
> Support was just added for specifying commit and path within url. So, we
> could actually just deprecate "subdir". and have "url" or "path"
>
> E.g.: url="some/path.git" would specify a git URL relative to the current
> plugin's git url.
> E.g.: url="#branch2" would specify a branch on the current URL
> (cordova-labs style)
> E.g.: url="#branch2:plugins/A" would specify a branch on the current URL
> plus a subdir within it.
> E.g.: url="#:plugins/A" would be invalid. (Use path if you just want to
> set the path)
> E.g.: path="../B" is always a relative fs path. If the current plugin is
> from git, then be careful not to go above the git root.
>
>
> On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>> Mulling this over a bit, I think I would like a solution for specifying
>> dependancies that would work regardless of where/how the plugins are
>> hosted, git or local.  If you had:
>>
>> BB_PLUGINS/
>> - plug1/
>> - plug2/
>> ...
>>
>> (and plug1 depends on plug2), then:
>>
>> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..   cordova
>> plugin add GIT_REPO:BB_PLUGINS/plug1
>>
>> ..should both work without changing all of the dependency tags in plug1.
>>  Actually, the plugin author should not have an explicit say in how a user
>> manages these directories (except in the directory structure).  Note that
>> this situation applies whenever a user clones your plugin repo to locally,
>> or for the reverse direction, when ever they add your plugins into their
>> teams' git repo.
>>
>>
>> Right now, thats not possible, because when installing from local path
>> with
>> url="." there is no way to know which of the plugins parent directories to
>> consider as the "root".  We could resolve this using several ways, among
>> them:
>>
>> (1) Jeffreys proposal: dropping the url="." means "path relative to this
>> plugin" (note however, that I propose it also works when installing from a
>> git repo).  Deprecate/warn against using url=".".
>>
>> (2) Support a new special file to "mark" the plugin root dir so we can
>> walk
>> the directory tree to find the valid target for url="." (ie, replace the
>> requirement for a .git with a requirement for a .cordova_repo, which BB
>> and
>> others could place within their plugin bundle).
>>
>>
>> I like (1).
>>
>> -Michal
>>
>>
>> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org> wrote:
>>
>> > Sounds reasonable to me.
>> >
>> > Conceptually, I'm not sure why the syntax for (2) shouldn't do what you
>> > request when the url for the original plugin was a local path?  Maybe
>> just
>> > a bug?
>> >
>> > -Michal
>> >
>> >
>> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <
>> jheifetz@blackberry.com>wrote:
>> >
>> >> We were working on a redistribution of Cordova that included some
>> plugins
>> >> and ran into a use-case not covered by the current plugin spec.[1]
>> >>
>> >> Currently there are two ways to specify a dependency
>> >> 1. Using a combination of url, commit and subdir which plugman will use
>> >> to clone down a repo and install
>> >> 2. Set the url to ".", skip the commit and specify a subdir relative to
>> >> the root of the repo. Plugman then runs git-rev parse to find the root
>> and
>> >> install from there.
>> >>
>> >> I would like to propose a third way which would be relative to the
>> >> current install and not use git at all
>> >> 3. Skip the url, skip the commit and specify a subdir relative to the
>> >> current plugin.xml.
>> >>
>> >> This would allow us to distribute a version of cordova with plugins to
>> >> anyone without an unnecessary requirement on git (considering the
>> plugins
>> >> are fully installed)
>> >>
>> >>
>> >>
>> >> 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>> >>
>> >> ---------------------------------------------------------------------
>> >> This transmission (including any attachments) may contain confidential
>> >> information, privileged material (including material protected by the
>> >> solicitor-client or other applicable privileges), or constitute
>> non-public
>> >> information. Any use of this information by anyone other than the
>> intended
>> >> recipient is prohibited. If you have received this transmission in
>> error,
>> >> please immediately reply to the sender and delete this information from
>> >> your system. Use, dissemination, distribution, or reproduction of this
>> >> transmission by unintended recipients is not authorized and may be
>> unlawful.
>> >>
>> >
>> >
>>
>
>

Re: Non-Git Plugin Dependencies

Posted by Andrew Grieve <ag...@chromium.org>.
Agree the use-case is valid. Here's a variation on (1) that I think is
marginally nicer:

url="." to be made optional, but default value is "."
subdir="" works only with git repos and is always relative to the root of
the repo.
path="" works with git repos or local paths and is relative to the
plugin.xml of the current plugin. You can't have "url" or "subdir" if you
have "path".

Support was just added for specifying commit and path within url. So, we
could actually just deprecate "subdir". and have "url" or "path"

E.g.: url="some/path.git" would specify a git URL relative to the current
plugin's git url.
E.g.: url="#branch2" would specify a branch on the current URL
(cordova-labs style)
E.g.: url="#branch2:plugins/A" would specify a branch on the current URL
plus a subdir within it.
E.g.: url="#:plugins/A" would be invalid. (Use path if you just want to set
the path)
E.g.: path="../B" is always a relative fs path. If the current plugin is
from git, then be careful not to go above the git root.


On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny <mm...@chromium.org> wrote:

> Mulling this over a bit, I think I would like a solution for specifying
> dependancies that would work regardless of where/how the plugins are
> hosted, git or local.  If you had:
>
> BB_PLUGINS/
> - plug1/
> - plug2/
> ...
>
> (and plug1 depends on plug2), then:
>
> cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..   cordova
> plugin add GIT_REPO:BB_PLUGINS/plug1
>
> ..should both work without changing all of the dependency tags in plug1.
>  Actually, the plugin author should not have an explicit say in how a user
> manages these directories (except in the directory structure).  Note that
> this situation applies whenever a user clones your plugin repo to locally,
> or for the reverse direction, when ever they add your plugins into their
> teams' git repo.
>
>
> Right now, thats not possible, because when installing from local path with
> url="." there is no way to know which of the plugins parent directories to
> consider as the "root".  We could resolve this using several ways, among
> them:
>
> (1) Jeffreys proposal: dropping the url="." means "path relative to this
> plugin" (note however, that I propose it also works when installing from a
> git repo).  Deprecate/warn against using url=".".
>
> (2) Support a new special file to "mark" the plugin root dir so we can walk
> the directory tree to find the valid target for url="." (ie, replace the
> requirement for a .git with a requirement for a .cordova_repo, which BB and
> others could place within their plugin bundle).
>
>
> I like (1).
>
> -Michal
>
>
> On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > Sounds reasonable to me.
> >
> > Conceptually, I'm not sure why the syntax for (2) shouldn't do what you
> > request when the url for the original plugin was a local path?  Maybe
> just
> > a bug?
> >
> > -Michal
> >
> >
> > On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <jheifetz@blackberry.com
> >wrote:
> >
> >> We were working on a redistribution of Cordova that included some
> plugins
> >> and ran into a use-case not covered by the current plugin spec.[1]
> >>
> >> Currently there are two ways to specify a dependency
> >> 1. Using a combination of url, commit and subdir which plugman will use
> >> to clone down a repo and install
> >> 2. Set the url to ".", skip the commit and specify a subdir relative to
> >> the root of the repo. Plugman then runs git-rev parse to find the root
> and
> >> install from there.
> >>
> >> I would like to propose a third way which would be relative to the
> >> current install and not use git at all
> >> 3. Skip the url, skip the commit and specify a subdir relative to the
> >> current plugin.xml.
> >>
> >> This would allow us to distribute a version of cordova with plugins to
> >> anyone without an unnecessary requirement on git (considering the
> plugins
> >> are fully installed)
> >>
> >>
> >>
> >> 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
> >>
> >> ---------------------------------------------------------------------
> >> This transmission (including any attachments) may contain confidential
> >> information, privileged material (including material protected by the
> >> solicitor-client or other applicable privileges), or constitute
> non-public
> >> information. Any use of this information by anyone other than the
> intended
> >> recipient is prohibited. If you have received this transmission in
> error,
> >> please immediately reply to the sender and delete this information from
> >> your system. Use, dissemination, distribution, or reproduction of this
> >> transmission by unintended recipients is not authorized and may be
> unlawful.
> >>
> >
> >
>

Re: Non-Git Plugin Dependencies

Posted by Michal Mocny <mm...@chromium.org>.
Mulling this over a bit, I think I would like a solution for specifying
dependancies that would work regardless of where/how the plugins are
hosted, git or local.  If you had:

BB_PLUGINS/
- plug1/
- plug2/
...

(and plug1 depends on plug2), then:

cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1    ..and..   cordova
plugin add GIT_REPO:BB_PLUGINS/plug1

..should both work without changing all of the dependency tags in plug1.
 Actually, the plugin author should not have an explicit say in how a user
manages these directories (except in the directory structure).  Note that
this situation applies whenever a user clones your plugin repo to locally,
or for the reverse direction, when ever they add your plugins into their
teams' git repo.


Right now, thats not possible, because when installing from local path with
url="." there is no way to know which of the plugins parent directories to
consider as the "root".  We could resolve this using several ways, among
them:

(1) Jeffreys proposal: dropping the url="." means "path relative to this
plugin" (note however, that I propose it also works when installing from a
git repo).  Deprecate/warn against using url=".".

(2) Support a new special file to "mark" the plugin root dir so we can walk
the directory tree to find the valid target for url="." (ie, replace the
requirement for a .git with a requirement for a .cordova_repo, which BB and
others could place within their plugin bundle).


I like (1).

-Michal


On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny <mm...@chromium.org> wrote:

> Sounds reasonable to me.
>
> Conceptually, I'm not sure why the syntax for (2) shouldn't do what you
> request when the url for the original plugin was a local path?  Maybe just
> a bug?
>
> -Michal
>
>
> On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <jh...@blackberry.com>wrote:
>
>> We were working on a redistribution of Cordova that included some plugins
>> and ran into a use-case not covered by the current plugin spec.[1]
>>
>> Currently there are two ways to specify a dependency
>> 1. Using a combination of url, commit and subdir which plugman will use
>> to clone down a repo and install
>> 2. Set the url to ".", skip the commit and specify a subdir relative to
>> the root of the repo. Plugman then runs git-rev parse to find the root and
>> install from there.
>>
>> I would like to propose a third way which would be relative to the
>> current install and not use git at all
>> 3. Skip the url, skip the commit and specify a subdir relative to the
>> current plugin.xml.
>>
>> This would allow us to distribute a version of cordova with plugins to
>> anyone without an unnecessary requirement on git (considering the plugins
>> are fully installed)
>>
>>
>>
>> 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute non-public
>> information. Any use of this information by anyone other than the intended
>> recipient is prohibited. If you have received this transmission in error,
>> please immediately reply to the sender and delete this information from
>> your system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be unlawful.
>>
>
>

Re: Non-Git Plugin Dependencies

Posted by Michal Mocny <mm...@chromium.org>.
Sounds reasonable to me.

Conceptually, I'm not sure why the syntax for (2) shouldn't do what you
request when the url for the original plugin was a local path?  Maybe just
a bug?

-Michal


On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz <jh...@blackberry.com>wrote:

> We were working on a redistribution of Cordova that included some plugins
> and ran into a use-case not covered by the current plugin spec.[1]
>
> Currently there are two ways to specify a dependency
> 1. Using a combination of url, commit and subdir which plugman will use to
> clone down a repo and install
> 2. Set the url to ".", skip the commit and specify a subdir relative to
> the root of the repo. Plugman then runs git-rev parse to find the root and
> install from there.
>
> I would like to propose a third way which would be relative to the current
> install and not use git at all
> 3. Skip the url, skip the commit and specify a subdir relative to the
> current plugin.xml.
>
> This would allow us to distribute a version of cordova with plugins to
> anyone without an unnecessary requirement on git (considering the plugins
> are fully installed)
>
>
>
> 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>