While I believe we could be able to specify everything with a single parameter, I don't follow what problem we're trying to solve by doing so.
If I understand everything correctly we're comparing the following; <dependency src=url#branch:subdir /> <dependency url=url commit=branch subdir=subdir /> While both seem reasonable and I do like the first, this seems unnecessary. On 13-09-04 3:18 PM, "Braden Shepherdson" <bra...@chromium.org> wrote: >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. >>>>>>>>>> >>>> >> >>>>>>>>>> >>>> > >>>>>>>>>> >>>> > >>>>>>>>>> >>>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> >> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> --------------------------------------------------------------------- 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.
