I think either is fine. Note that as of last week, it is fine to use
url#branch:subdir in dependency url values.
On Mon, Sep 9, 2013 at 1:06 PM, Anis KADRI wrote:
> I don't mind that but I think we should start relying on our registry
> from now on. It's so much simpler to specify a name and a
I don't mind that but I think we should start relying on our registry
from now on. It's so much simpler to specify a name and a version than
a long url, branch and subpath. I will write tests for this specific
case this week.
On Mon, Sep 9, 2013 at 9:05 AM, Jeffrey Heifetz wrote:
> So it seems I
So it seems I killed all discussion here, but before I did that I feel we
reached a consensus that relative dependencies are something we'd like to
support. The final decision to make is how we would like to do so.
Current Implementation . When url = "."
then the dependency is treated as living in
While I believe we could be able to specify everything with a single
parameter, I don't follow what problem we're trying to solve by doing so.
If I understand everything correctly we're comparing the following;
While both seem reasonable and I do like the first, this seems unnecessary.
O
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.
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
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 wrote:
> Sure, I can work with path="" instead. What happens if (when) a user
> supplies both?
>
>
> On
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 wrote:
>
>
>
> On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson
> wrote:
>
>> I believe the current logic is "a plugin with this ID is already
>> installed, so s
On Wed, Sep 4, 2013 at 11:22 AM, Braden Shepherdson 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 wrote:
>
>> .. but either way if we add
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
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 wrote:
> .. but either way if we add support for filesystem-relative paths and they
> work when fetching the
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 wrote:
> I like where this is generally going, but I want to correct one mistake
> Michal made. There /is/ a way to know
.. 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 c
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
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 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
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
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
plug
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
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 wrote:
> We were working on a redistribution of Cordova tha
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 insta
20 matches
Mail list logo
