https://issues.apache.org/jira/browse/CB-5006
On Thu, Oct 3, 2013 at 4:57 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > @Michal SGTM. The original approach has some other benefits on top of > the current requirements. However, I don't know if we need those > benefits just yet. > > On Thu, Oct 3, 2013 at 6:06 PM, Carlos Santana <csantan...@gmail.com> > wrote: > > 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> >
