couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <si...@cloudant.com>
Subject Re: Simplifying Fauxton Setup
Date Thu, 31 Jan 2013 13:33:16 GMT
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 <russell@cloudant.com (mailto:russell@cloudant.com)>
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
> --  




Mime
View raw message