Re: testing 2.13.7, bumped fontforge+double

[Graham Percival]

On Fri, Nov 06, 2009 at 08:32:06AM +0100, Jan Nieuwenhuizen wrote:
> Op donderdag 05-11-2009 om 22:23 uur [tijdzone +0000], schreef Graham
> Percival:
> > Jan, since you know both python and GUB, could you try making the
> > lilypond scripts on darwin  (convert-ly, lilypond-book, etc)
> > point to the python that we distribute with lilypond, rather than
> > #!/usr/bin/env?  I think that might fix
> > http://code.google.com/p/lilypond/issues/detail?id=894
> 
> This issue looks like an installation error on part of reporter.
> Reporter seems to have a [partly/roken] python [library] installed 
> in his home directory.  Don't do that -- or don't write bug
> reports when doing that ;-)

Good point.

Can anybody without any manual python stuff reproduce this bug?
If not, we can just close it.

> Moreover, python2.6 should be able to import md5 [try it on your
> linux box] /and/ all lilypond scripts should "just" run with
> python2.6 -- otherwise we'd have a slew of problems with just
> about any linux distro.
> 
> Furthermore, I do not have much darwin knowledge, and it seems
> that someone more knowledgable than me [Han-Wen?] has explicitly
> specified to use darwin's native python by setting
> 
>     make_flags = ' TARGET_PYTHON="/usr/bin/env python"'
> 
> unfortunately, there is no comment there, but I would suggest
> not to change it unless you know what you are doing.

That line is there because osx 10.4 comes with python 2.3.5, which
isn't compatible with lilypond-book (we use set) or convert-ly (we
use decorator functions).

The old workaround was to install python (via fink, macports, or
manually) and then manually edit the lilypond python scripts to
use "/usr/bin/env python"  instead of /usr/bin/python.

However, at approximately the same time that we changed the
TARGET_PYTHON, we also started distributing python2.6 in the osx
package  (... I think?), which IMO calls into question whether we
should still use /usr/bin/env, or switch to looking at the python
we distribute.


I mean, what if somebody installs python 3.1?  It would be nice to
avoid spurious bug reports.  ;)

Cheers,
- Graham