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 15:22:51 GMT
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.
>>>
>>> (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