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