@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>
