Here's another use-case: - You have a github account - You have one plugin per repo - URLs look like: https://github.com/MobileChromeApps/AppBundle.git - You want AppBundle to depend on https://github.com/MobileChromeApps/zip.git - You want this to work when you've got your plugins checked out for local dev: plugins/AppBundle.git plugins/zip.git
You try <dependency src="zip.git" /> If we treated this as a relative URL, then it would actually work in both cases (online or checked out). If we treat non-absolute-urls as subdirs, then things don't work out for this use-case. If we use path= for subdirs and url= for repo URLs, then both use-cases work out. On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mmo...@chromium.org> wrote: > 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 <bra...@chromium.org>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 <agri...@chromium.org>wrote: >> >>> >>> >>> >>> 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. >>>>>>>> >>>> >> >>>>>>>> >>>> > >>>>>>>> >>>> > >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >> >>>>>>>> > >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
