On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny <mmo...@chromium.org> wrote:
> > > > On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI <anis.ka...@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 <mmo...@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 <agri...@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 < >> agri...@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" <agri...@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. >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> >> > >
