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