cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Mapping plugin ID -> URL
Date Thu, 03 Oct 2013 14:27:06 GMT
On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny <mmocny@chromium.org> wrote:

>
>
>
> On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
>
>> Braden and I have talked about it in the past but there is already a
>> $HOME/.plugman/cache and plugman will not attempt to fetch plugins if
>> they are already in the cache. Unless I am missing something can you
>> just not drop your dependencies in there?
>>
>
> This sounds like it would work, but I'm hesitant to force a global
> installation of the cache.  I think it would mean you cannot develop BB
> webworks apps on the same machine as you develop vanilla cordova apps since
> the same plugin id would map to different places across *all* plugman using
> projects.
>
> Note that it already has been a source of problems to have things
> needlessly added to ~/.cordova and ~/.plugman.
>

Thinking about this more, I think using the global cache is subtly
different than what we want here.  However, I think we could perhaps
leverage the concept and share most of the code.  Here is the big
difference:

- The global plugman cache is used *after* going out to registry to lookup
latest version, so as not to download the same plugin version multiple
times.
- This proposed local search path is to be used *before* going out to
registry, without caring about its content or version number.

Perhaps the current behaviour can be decomposed into two steps: (1) "update
global cache with newest plugin version via registry" and (2) "install
plugin from cache".  Then, installing a plugin by ID could be:

- Attempt Step (2) from local search path(s)
- then, if above failed, do Step (1)
- then, if above succeeded, Attempt Step (2) from global cache

How does that sound?


>
>>
>> Are there other use cases than simply 'not fetching from registry and
>> using local path' for a given plugin ID ?
>>
>
> I think this is the only use case we are looking to solve, but it shows up
> in different situations: during cordova plugin add ID or plugman --install
> with <dependancy> etc.
>
>
>>
>> #1 and #2 can be solutions to some problems but do we have those
>> problems yet ? They can be a solution to managing multiple registry
>> sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...)
>> because right now we only support.
>>
>
> Yes, we already do have these problems, as said: IBM, BB, and to some
> extent Mobile-Chrome-Apps is already needing this solution.  Implementing a
> new registry would be fine, if it worked offline for local-only installs,
> preferably without the need to set up a server/couchdb for such simple
> local only mappings, which is exactly Andrews proposal.
>
>
>>
>> Your proposed changes also seem to only affect CLI since you mentioned
>> a ".cordova/config.json". plugman only users would potentially be
>> penalized once again.
>>
>
> I completely agree this is implemented in plugman.  We are discussing CLI
> just to establish the convention for how to store the cache, but plugman
> would have all the underlying functionality.  It *has* to be this way,
> since its the one that resolves dependencies, and will need a new argument
> alongside --install to know where to lookup id for local mapping.
>
>
>>
>> On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny <mmocny@chromium.org> wrote:
>> > I think the missing piece is that the plugin author has the option of
>> > specifying dependencies in terms exactly *one* of these options:
>> >
>> > (a) id, to be looked up in the registry
>> > (b) explicit git url
>> > (c) relative path
>> >
>> > The problem is that a downstream *distributor* cannot override these
>> values
>> > at the moment, without making direct edits to the plugin.xml.  e.g. IBM
>> and
>> > BlackBerry have already both spoken up about the problem of shipping a
>> > cordova based tool with plugins bundled, and having full control over
>> > plugin versions, supporting offline work, etc.
>> >
>> > How can we solve the generic case of using the CLI with the registry,
>> while
>> > supporting the bundling/tarball use case?
>> >
>> > Andrews proposal would allow for option (a) to be overwritten by a
>> > distributor without changes to the plugin.xml, by implementing a local
>> > workspace mapping of id -> path, which is used by cli instead of
>> reaching
>> > out to the registry (though it could still use the registry for id's
>> that
>> > are not in the mapping).
>> >
>> > I suspect it would also make (a) the only necessary way to specify
>> plugin
>> > dependencies in practice, which I think is a win for simplicity.  Thats
>> my
>> > understanding anyway.
>> >
>> > -Michal
>> >
>> >
>> > On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux <b@brian.io> wrote:
>> >
>> >> Well, not npm but rather http://plugins.cordova.io or by URL or by
>> >> relative
>> >> path (allowing for vendored plugins). That is how Node does it TMK and
>> >> should cover our use cases too without adding new config file options
>> (or
>> >> worse more config files).
>> >>
>> >> Am I missing something?
>> >>
>> >>
>> >> On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve <agrieve@chromium.org>
>> >> wrote:
>> >>
>> >> > Could you give an example of how you'd use npm or vendor
>> dependencies?
>> >> >
>> >> >
>> >> > On Wed, Oct 2, 2013 at 10:12 AM, Brian LeRoux <b@brian.io> wrote:
>> >> >
>> >> > > 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.
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message