I'm not convinced that all use cases cannot be handled with a single attribute. Maybe url / path are the wrong names, maybe a single src="".
On Wed, Sep 4, 2013 at 1:21 PM, Braden Shepherdson <[email protected]>wrote: > 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. >>>>>>> >>>> >> >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> >>>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
