Re: lilypond.org can't build website

[Phil Holmes]

----- Original Message ----- 
From: "Graham Percival" <address@hidden>
To: "Phil Holmes" <address@hidden>
Cc: <address@hidden>
Sent: Saturday, September 17, 2011 5:15 PM
Subject: Re: lilypond.org can't build website


> On Sat, Sep 17, 2011 at 01:27:24PM +0100, Phil Holmes wrote:
> > Patch attached which runs on a standalone website build on my
> > system.  I believe this should fix your website build problem.
>
> That patch hard-codes the lilypond-git directory unnecessarily; we
> have already defined TOP_SRC_DIR, so why not use
> $TOP_SRC_DIR/python ?

Good point.  I've slightly lost track of who's doing what on this now, 
though, so I'll not change my local website.make.

> > A further comment on the "copy the langdefs" script to safe-scripts.
> > If we do that, we'll need to amend website.make again...
>
> oops, I forgot about that.  So actually we don't want to point to
> TOP_SRC_DIR/python/ at all, since that's untrusted material.

I think this is your point 1. below.

> I can't shake the feeling that we've taken a wrong turn somewhere.
> The original motivation behind "avoid hard-coding/duplicating the
> list of languages" was to simplify the build process, right?  But
> all this "run a python script with an argument to get a list of
> languages" stuff seems to be un-simple.  I'm wondering if a
> radically different approach would be good.
>
> What about a plain old text file?  If we had a languages.txt (just
> like VERSION), we could cat that file in website.make with no
> security concerns.  And langdefs.py could read that file with no
> problems.  Or... do we need an actual hard-coded list of languages
> at all?  What if we just make a list from all two-character
> sub-directories of Documentation/ ?  actually, maybe that's a
> silly idea; updating a single list of languages in one place isn't
> hard, and that could avoid some potential problems if somebody
> wanted to make a non-language two-character subdirectory of
> Documentation/

I must admit to finding langdefs.py rather over-kill for what we actually 
use it for.  It seems to me the functional definition is quite simple - 
return a list of language abbreviations to either a make file or a python 
file which needs it.  However, we do need to ensure that 2 lists are 
available: web and doc.

Note Reinhold's mail about the errors from langdefs.  Making this simpler 
would stop those, too.

> ... ok, I'm rambling (I have a mild fever), and this isn't helping
> to solve the immediate problem.

I'm struggling with a visual migraine, so a bit ditto.

> 1. amend the CG page to include langdefs.py in the "trusted
> scripts" stuff.  I'll copy that over.
> 2. set PYTHONPATH to be $TRUSTED_SCRIPTS_DIR (or whatever it's
> called) in website.make.

See above - you gonna do this?


--
Phil Holmes