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