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 15:20:53 GMT
.. 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