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 <jheif...@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" <jheif...@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" <bra...@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 <agri...@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 <mmo...@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 >>>>><bra...@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 >>>>>><agri...@chromium.org>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson < >>>>>>> bra...@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 >>>>>>>><mmo...@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 >>>>>>>>><mmo...@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 < >>>>>>>>>> bra...@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 >>>>>>>>>>><mmo...@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 < >>>>>>>>>>>> agri...@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 < >>>>>>>>>>>> mmo...@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 < >>>>>>>>>>>> agri...@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 < >>>>>>>>>>>> mmo...@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 < >>>>>>>>>>>> mmo...@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 < >>>>>>>>>>>> >>>> jheif...@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.
