cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Non-Git Plugin Dependencies
Date Wed, 04 Sep 2013 17:42:51 GMT
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 <braden@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 <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