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 17:21:52 GMT
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 <agrieve@chromium.org> wrote:

>
>
>
> 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