cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Non-Git Plugin Dependencies
Date Wed, 04 Sep 2013 18:33:44 GMT
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