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 <[email protected]> wrote: > > > > On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson > <[email protected]>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 <[email protected]>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 <[email protected]>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 < >>>> [email protected]> 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 <[email protected]>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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>> 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 < >>>>>> [email protected]>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 < >>>>>> [email protected]>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 < >>>>>> [email protected]> >>>>>> >>>> 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 < >>>>>> >>>> [email protected]>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. >>>>>> >>>> >> >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>> >>>>>> >>> >>>>>> >>> >>>>>> >> >>>>>> > >>>>>> >>>>> >>>>> >>>> >>> >> >
