cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Non-Git Plugin Dependencies
Date Wed, 04 Sep 2013 14:38:15 GMT
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.

(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 <mmocny@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 <agrieve@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 <mmocny@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 <agrieve@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 <mmocny@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 <mmocny@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 <
> >>>> jheifetz@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.
> >>>> >>
> >>>> >
> >>>> >
> >>>>
> >>>
> >>>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message