couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Simplifying Fauxton Setup
Date Thu, 31 Jan 2013 21:54:27 GMT

On Jan 31, 2013, at 21:13 , Russell Branca <chewbranca@gmail.com> wrote:

> On Thu, Jan 31, 2013 at 5:33 AM, Simon Metson <simon@cloudant.com> wrote:
> 
>> 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
>>> --
>> 
>> 
>> 
>> 
> 
> Interesting point about updating the $PATH Jan. I'm not opposed to going
> back to installing grunt and bbb globally, although one intermediate option
> that might work well is to just add a bin folder and add proxy scripts for
> grunt and bbb that just point into node_modules/.bin/.

Yeah, this sounds sensible.


> I really like the idea of allowing you to just point at a CouchDB server
> and run with it, it would definitely simplify Fauxton dev for front end
> people to avoid having to install couchdb directly, this is something we've
> already had issues with, so I'm happy to take an alternative approach here.
> 
> I'll look more into options for getting the development server working,
> we're 90% there, just need to figure out whether the best approach is
> something like Gregor's proxy, or using CORS directly, or something else.

CORS is disabled by default in CouchDB 1.3.x and later. Gregor’s proxy simply
CORSifies any HTTP API without any configuration, it couldn’t be simpler. I
highly suggest we look at that. (I really should set this up for myself here,
so I don’t feel like an idiot suggesting stuff)

Best
Jan
-- 





Mime
View raw message