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 19:18:23 GMT
Not quite, since the checked-out directories generally don't have the
".git" suffix; you'd have to override git's normal naming behavior when
cloning these.

I think that's quite a bit of delicate magic we don't need. I think src
might be a better name, if we wanted to go with a single parameter.

If we want to go with two, I like url and path. Supplying both and choosing
based on where the parent plugin was fetched from, that would probably work.

I think src="" and my three use cases above works. Thoughts?

Braden


On Wed, Sep 4, 2013 at 2:33 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Here's another use-case:
> - You have a github account
> - You have one plugin per repo
> - URLs look like: https://github.com/MobileChromeApps/AppBundle.git
> - You want AppBundle to depend on
> https://github.com/MobileChromeApps/zip.git
> - You want this to work when you've got your plugins checked out for local
> dev:
> plugins/AppBundle.git
> plugins/zip.git
>
> You try <dependency src="zip.git" />
>
> If we treated this as a relative URL, then it would actually work in both
> cases (online or checked out). If we treat non-absolute-urls as subdirs,
> then things don't work out for this use-case. If we use path= for subdirs
> and url= for repo URLs, then both use-cases work out.
>
>
>
>
> On Wed, Sep 4, 2013 at 1:42 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
>> 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