Return-Path: 
 <dev-return-26755-apmail-cordova-dev-archive=cordova.apache.org@cordova.apache.org>
X-Original-To: apmail-cordova-dev-archive@www.apache.org
Delivered-To: apmail-cordova-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 05E7A10773
	for <apmail-cordova-dev-archive@www.apache.org>;
 Wed,  2 Oct 2013 09:13:45 +0000 (UTC)
Received: (qmail 79710 invoked by uid 500); 2 Oct 2013 09:13:41 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 78770 invoked by uid 500); 2 Oct 2013 09:13:26 -0000
Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cordova.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cordova.apache.org>
List-Post: <mailto:dev@cordova.apache.org>
List-Id: <dev.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list dev@cordova.apache.org
Received: (qmail 78700 invoked by uid 99); 2 Oct 2013 09:13:22 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Oct 2013 09:13:22 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com
 designates 74.125.82.172 as permitted sender)
Received: from [74.125.82.172] (HELO mail-we0-f172.google.com) (74.125.82.172)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Oct 2013 09:13:18 +0000
Received: by mail-we0-f172.google.com with SMTP id w61so591540wes.3
        for <dev@cordova.apache.org>; Wed, 02 Oct 2013 02:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date:message-id:subject
         :from:to:content-type;
        bh=t2E/xSdHdHYWeqm2oMeWw5FGkyEHGUC7S+F9w50qf1o=;
        b=Erll7dW7Aric94QKmBX7b9+ZMYJcKwSXciQ0DhbzfuQ8PzbTBzGIVe6B02FF9wsPMH
         WQnMlTD5RGDP04+hOooElKD7ZMIubaEaHIZkeaNChUVwEeHX2DbKg6r1f7ygI6mcIdyD
         aFNnUbYXU3rGp9HI8WlLF7z10fiy+doWVge1YUeHVerOfYLLLBILtYYoMC9fSa7F1fVv
         pKnJqG6dLKtOysmj54CTHLyOxAgerCDZonqNKooLJbxB64VDXGx38IhUxE0VVNITb0rY
         qKY5F2Jo4D1KDFfW25f8toxD6SOToFIFNsUQgQh5e1RZQA6LzCc259HfHAy+p1xiq1bG
         NMng==
MIME-Version: 1.0
X-Received: by 10.194.93.105 with SMTP id ct9mr1248632wjb.6.1380705176944;
 Wed, 02 Oct 2013 02:12:56 -0700 (PDT)
Sender: brian.leroux@gmail.com
Received: by 10.194.87.98 with HTTP; Wed, 2 Oct 2013 02:12:56 -0700 (PDT)
In-Reply-To: 
 <CABiQX1UJ65KkpaNrOqr0YL4MJQyL2Jq3rQ+z1C2yRdAW9VUM9Q@mail.gmail.com>
References: 
 <CABiQX1WjpGvbX+Rmcsu4_vcmT0Uy8xze9kTWBAJjbkpcUQksZQ@mail.gmail.com>
	<CADVgkyNxADbRO7mbFPgVKycMHrdW9HmrKw1eQO3uMkBfgAmYeg@mail.gmail.com>
	<CABiQX1UJ65KkpaNrOqr0YL4MJQyL2Jq3rQ+z1C2yRdAW9VUM9Q@mail.gmail.com>
Date: Wed, 2 Oct 2013 10:12:56 +0100
X-Google-Sender-Auth: 1ggxoA6LtPFH4mLlxcnNJ2bdvb0
Message-ID: 
 <CADVgkyOGdaX4=VoB+LST1dEmQcX30RJiVfbpspZKtNe8pefoXg@mail.gmail.com>
Subject: Re: Mapping plugin ID -> URL
From: Brian LeRoux <b@brian.io>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7bb03e789c87e204e7be79af
X-Virus-Checked: Checked by ClamAV on apache.org

--047d7bb03e789c87e204e7be79af
Content-Type: text/plain; charset=ISO-8859-1

Ok, wanted clarity there. Node tried similar approaches and ultimately they
lead to complexity pain, and module author suffering.

The recommended way (now) is npm or bundle/vendor dependencies. I think
this is sane and easier. Could be convinced of the 'id' field allowing for
a Git url though.


On Wed, Oct 2, 2013 at 1:41 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> E.g. for mobile-spec's dependency-plugin, it has <dependency
> id="org.apache.cordova.file"> Instead of having plugman download it from
> the registry, I'd like to tell it to look for it locally.
>
> Not entirely sure what you mean by project level deps (do those exist)?
>
>
> On Wed, Oct 2, 2013 at 12:45 AM, Brian LeRoux <b@brian.io> wrote:
>
> > So wait, the use case is proj level deps not plugin level?
> > On Oct 1, 2013 10:50 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >
> > > There is a need to have plugman look in places other than the registry
> > when
> > > fetching plugins by ID. This is particularly the case because
> > <dependency>
> > > plugins now have IDs only instead of specifying a URL.
> > >
> > > Downstream distributions need this (e.g. IBM packages plugins with
> their
> > > distro). But this would be nice for mobile-spec as well (dependency
> > plugin
> > > could just list IDs instead of plugin paths).
> > >
> > > Idea #1:
> > > Add a map to a project's .cordova/config.json with explicit ID -> URL
> > > mappings. E.g.:
> > > "plugin_map": {
> > >   "org.apache.cordova.file": "file:///some/path",
> > >   "org.apache.cordova.file-transfer": "http://git.com/url#hash"
> > > }
> > >
> > > Idea #2
> > > Add the idea of "plugin search path"
> > > e.g.:
> > > .cordova/config.json
> > >    "plugin_search_path": ["file:///my/local/plugins", "
> > > http://my/custom/couch/db", "<inherits>"]
> > >
> > > Entries here can be:
> > >   1. local directory where each subdirectory contains a plugin
> > >   2. http:// to a couchdb of a custom registry
> > >   3. <inherits>, which means prepend this list instead of replacing the
> > > setting.
> > >
> > >
> > > Idea #3
> > > Allow the user to copy / symlink the plugin sources into a projects
> > > plugins/ directory. The directory names in here would need to be the
> > plugin
> > > IDs. When a request to install a plugin is made, plugman will first
> check
> > > if it already exists within plugins/, and if so, uses that source. It
> > would
> > > also need to know not to delete the directory on plugin rm.
> > >
> > >
> > >
> > > #1 is nice because it's simple, but may not be super convenient (since
> > you
> > > need to explicitly add each plugin). It's also the only suggestion that
> > > allows you to map an ID to a custom git URL
> > > #2 will work well for plugin collections, but may be annoying if you
> just
> > > want to override a single plugin location.
> > > #3 is arguably the most flexible since it leaves the fetching
> completely
> > up
> > > to the user. It may encourage people to muck with their plugins/ to the
> > > point of breaking their project though. (e.g. they may delete plugins
> > that
> > > are installed)
> > >
> > >
> > > I think I'd lean towards allowing both #1 and #2.
> > >
> >
>

--047d7bb03e789c87e204e7be79af--