I think plugman is trying to do more than it should. We should look into something like bower to handle dependencies and fetching them to a local folder for a project. Bower can be use by user via cli and plugman can use it as a node library.
Bower handles the download of packages/repo with it's versions/tags to a local folder. I see a cordova plugin be analogous and not that different from a package. Then plugman uses a local folder (bower_components, cordova_components, or what ever name) to install plugins from that folder. Cache only solved the problem of network usage, it doesn't solve portability of a project/repo. I'm out on vacation but wanted to bring up Bower for front-end dependencies. We can leverage their lessons learned or their code and we don't have to re-invent the wheel. TLDR: I vote for plugman to have an option for install command to skip the registry and use local folder already populated with a set of plugins. -- Carlos On Thursday, October 3, 2013, Michal Mocny wrote: > On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny > <mmo...@chromium.org<javascript:;>> > wrote: > > > > > > > > > On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI > > <anis.ka...@gmail.com<javascript:;>> > 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? > >> >> > > >> >> > > >> >> -- Carlos Santana <csantan...@gmail.com>
