Flipping this to dev@ so others can chime in.
On Thursday, 31 January 2013 at 12:49, Jan Lehnardt wrote: > Excellent work Russell, > > just a few notes. CC’d Gregor, too. > > On Jan 31, 2013, at 02:10 , Russell Branca <[email protected] > (mailto:[email protected])> wrote: > > > So I switched the majority of deps in Fauxton over to being declared in > > package.json so that we can install them directly with npm install. > > > > The tricky bit is that both bbb and grunt want to be installed globally so > > that you can more easily say bbb foo. However, the only real motivation > > there is a question of pathing, there is no technical limitation to > > installing them into ./node_modules/grunt|bbb. > > > > I see two initial goals here, 1) simplify running this for new developers > > to more easily contribute, and 2) simplify the build process for > > incorporating this into the CouchDB build process. > > > > For new developers, ideally it should be just two steps, install deps and > > install into couchdb. If we move grunt and bbb into package.json, we can > > install all deps in one fell swoop. Then the devs can either can just do: > > > > export PATH=./node_modules/.bin:$PATH > > > > or we can add wrappers. Couple wrapper options. We can add some scripts to > > npm and execute them like "npm run-script couchdebug" which is a bit > > limiting as I don't think run-script picks up command line args. > > > > We could also add a makefile to wrap some of these items, but that might be > > overkill for this scenario given that we already have grunt and friends. > > > > For now, I'm just going to switch grunt and bbb over to being installed by > > npm locally into ./node_modules, and we can just update our paths. If > > needed we can add wrappers or other things to simplify working with it down > > the road. > > For web dev folks having to copy and paste: > > npm install -g bbb > npm install -g grunt > > from a README once is about 10000% easier than fiddling with environment > variables. It is of course the same to the more UNIXy folks among us, but we > saw during the Hoodie hacksession at CouchDB Conf that setting env vars, > remembering to do it in the other Terminal tab, not knowing how to make it > permanent etc. is a huge pain. There’s not much wrong with installing bbb and > grunt globally. > > The main point to simplify is the main workflow: > > 1. edit files > 2. reload the browser > 3. repeat > > And eventually > > 4. commit > > Or as close as we can get to it. > > (note I still have to set this all up myself, so I am slightly talking out of > my ass here :) > > > > The other big motivation here is simplifying the process for bundling this > > with CouchDB. We don't want to have to do global deps and local deps as > > part of running make. Installing grunt and bbb locally means we have direct > > absolute paths to these items and no global permission issues or any other > > global problems. > > This is a good call in the opposite direction :) — In that case, having top > level links to bbb and grunt that live in ./node_modules would do the trick. > > That said, this is only for building the distribution of CouchDB, right? This > isn’t something that anyone is expected to run themselves when building from > a release tarball? > > If Fauxton developers are fine with doing `npm -g`, then we can keep a level > of indirection out. If we need grunt & bbb for regular operation of CouchDB, > then that’s another story, but I hope we don’t need this :) > > > > Anyways, wanted to get some feedback from you guys, although after thinking > > about it more, I think setting the local path is a pretty simple and > > straightforward solution for this. > > > > One other item of interest, is that we get a development server for free > > from bbb that simplifies development, but we'll need to work around cross > > domain browsers issues with either a proxy or switching over to CORS. I > > think going with CORS would be the best approach, but we don't use that > > currently. > > CORS is easily done with https://github.com/gr2m/CORS-Proxy (it’s Gregor > again! :) > > > > Alright, going to switch over to installing locally and update the readme. > > For those who hadn’t seen it, I asked Gregor to write up a fake readme of how > he’d envision working on Fauxton: > > https://gist.github.com/4672813 > > We can’t exactly replicate it, but I think we can get close. > > My rough idea here is: > > - have Fauxton live in a separate git repo. ASF can give us > `couchdb-fauxton`, which would mirror to github.com/apache/couchdb-fauxton > (http://github.com/apache/couchdb-fauxton) with all the Pull Request benefits > that the main couchdb repo has. > > - issues would still go into ASF JIRA, sadly, but we can abuse Pull Requests > for issues. > > - have Fauxton sync into the main couchdb tree via git submodules. It ain’t > pretty, but it’s simple enough. > > - Be able to have a standalone build of Fauxton (from the proposed > couchdb-fauxton repo) hit a random CouchDB URL as its backend. CORS is an > issue, but since this is for devving only, it should be straightforward as a > single-line setup instruction or even be automated. — The idea is that > frontend devs don’t have to fiddle with the CouchDB source in any way. They > could dev Fauxton against Cloudant or IrisCouch if they wanted to, or the Mac > or Windows packages from couchdb.a.o. > > Note: I understand we went the way of keeping it in the couch source to keep > Noah and others in line and get Fauxton into the world, but I am now ready to > fight for the approach above (it’s a draft of course, whatever we can do to > make it better, let’s do it) that is optimised for contributability. > > Let’s do this! <3 > > Cheers > Jan > --
