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. > > (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. >> >>>> >> >> >>>> > >> >>>> > >> >>>> >> >>> >> >>> >> >> >> > >> > >
