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:15:19 GMT
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