cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Non-Git Plugin Dependencies
Date Wed, 04 Sep 2013 17:19:01 GMT
On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson <braden@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 <mmocny@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 <mmocny@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 <braden@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 <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