Not quite, since the checked-out directories generally don't have the ".git" suffix; you'd have to override git's normal naming behavior when cloning these.
I think that's quite a bit of delicate magic we don't need. I think src might be a better name, if we wanted to go with a single parameter. If we want to go with two, I like url and path. Supplying both and choosing based on where the parent plugin was fetched from, that would probably work. I think src="" and my three use cases above works. Thoughts? Braden On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <agri...@chromium.org> wrote: > 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. >>>>>>>>> >>>> >> >>>>>>>>> >>>> > >>>>>>>>> >>>> > >>>>>>>>> >>>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
