I agree that our agenda for next week's hangout is long enough already. In terms of releases being infeasible, I'm assuming you mean the fact we would have to vote on all of the components during a tools release. If we get some of these components stable enough, we would only need to vote on them when we change them (shouldn't be often) and not every tools release.
I'd love to get more details about your proposed first patch. What do you mean by "Move internal implementation details of plugman into cordova". I interpret it as move common functionality into cli, make plugman dependent on cli. If that is the case, wouldn't it make more sense to move the functionality into plugman since the cli already requires it? I like the end goals of your proposal, in that we are working towards smaller modules. I'm not sure if moving components from one repo to another is a better way to reach the end goal, instead of Mark's original suggestion of a third cordova-lib repo that both plugman + cli can depend on. On Fri, Apr 11, 2014 at 11:44 AM, Michal Mocny <mmo...@chromium.org> wrote: > Brian, > > Discussed this with Mark locally. We think you are right, if a > library/util has use outside of plugman/cli we should compartmentalize and > publish to npm. At the moment, the overhead of doing releases would make > this infeasible, and we should really plan ways to make this workflow > possible. I think the list of topics for next meetup is already long, so > lets add this to agenda for a future meetup (I doubt we have any > suggestions to fix the issue yet, anyway, we still have to automate how we > do core releases). > > So, here is our proposal: > First patches: Move internal implementation details of plugman into > cordova, leaving the CLI parsing, usage/help, and binary in that repo, so > it works 100% the same, except the require() paths change. > Next patches: move out existing common utilities from cordova/plugman into > subdirectories with names like cordova-util-foo. > Ongoing patches: refactor more of cordova/plugman to use standalone utils. > Eventually, when things settle: publish those utils which are useful > outside of cli/plugman. > > Mark has agreed to try these first steps in a feature branch of > plugman/cli, and will post once there is a working version. > > Any objections/suggestions? > > > On Thu, Apr 10, 2014 at 8:05 PM, Brian LeRoux <b...@brian.io> wrote: > > > More on this approach: > > > > http://blog.izs.me/post/48281998870/unix-philosophy-and-node-js > > https://blog.nodejitsu.com/the-nodejs-philosophy/ > > http://substack.net/how_I_write_modules > > > > > > On Fri, Apr 11, 2014 at 10:04 AM, Brian LeRoux <b...@brian.io> wrote: > > > > > I want more repos not less! I'd love for us to break the functionality > up > > > into a tonne of smaller utility repos. Ideally every module is in a > > > discreet git repo, separately versioned, and dependencies are managed > > with > > > npm. > > > > > > > > > On Fri, Apr 11, 2014 at 5:59 AM, Michal Mocny <mmo...@chromium.org> > > wrote: > > > > > >> The overhead of a third repo scares me. I'm fine with merging into a > > >> single repo, but I'll throw a third option into the mix: > > >> > > >> - Leave the plugman repo, and leave the plugman binary in there, but > > >> refactor to make plugman depend on cordova-cli, and forward all > > >> functionality to cli implementations. > > >> > > >> This leaves the APIs entirely untouched and is just an internal > > refactor. > > >> It would invert the "depends" direction, but I don't think that > > matters. > > >> > > >> -Michal > > >> > > >> > > >> On Thu, Apr 10, 2014 at 2:53 PM, Mark Koudritsky <kam...@google.com> > > >> wrote: > > >> > > >> > I often find myself making changes that require commits to both > > plugman > > >> and > > >> > cli, it's not always clear which repo new code should live in and > > >> sharing > > >> > utility functions between the two projects is not trivial. > > >> > > > >> > The idea of "cordova-lib" was mentioned several times on this > mailing > > >> list. > > >> > The lib would contain most of the code from both plugman and cli > while > > >> the > > >> > end tools will be thin wrappers around the lib. > > >> > > > >> > I wanted to probe how people working on CLI feel about such > > >> rearrangement. > > >> > > > >> > But if we are already in this discussion, now that the heavy > platforms > > >> > files are distributed separately from cordova-cli (repos like > > >> cordova-ios > > >> > etc), is there anything that prevents us from merging plugman and > cli > > >> into > > >> > a single npm package with 2 executables? > > >> > > > >> > > > >> > Examples of code that should be shared include: > > >> > - Common logging and error handling logic (e.g. CordovaError > > exception) > > >> > - Fetching logic (for plugins and platforms) > > >> > - Platform-specific logic (e.g. where the config.xml file lives > within > > >> each > > >> > project) > > >> > - Generic utilities like xml-helpers.js (currently copied but > slightly > > >> > diverged in the 2 repos) > > >> > > > >> > The first option that comes to mind is to create another repo and > > >> another > > >> > npm package for cordova-lib, but this creates significant overhead: > > >> > - Version release would get more difficult (see the failed release > > vote > > >> > thread < > > >> https://www.mail-archive.com/dev@cordova.apache.org/msg15419.html > > >> > >from > > >> > last Friday) > > >> > - In many cases new functionality in plugman or CLI would require > > >> changes > > >> > in 2 or even 3 repos. This is a significant additional barrier for > new > > >> > contributors that don't have commit rights - coordinating two > > >> > interdependent pull request is quite a hassle. > > >> > - Strictly speaking, cordova-lib major version number will have to > be > > >> > bumped every time we change some function signatures, which will > > happen > > >> > rather frequently in this case (this point also partially holds true > > if > > >> the > > >> > lib will be part of the plugman repo and npm package). > > >> > > > >> > Based on the points above a single repo and npm package containing > > both > > >> > plugman and cli seems to provide the most benefit. > > >> > > > >> > What do you think? > > >> > > > >> > > > > > > > > >
