Re: LilyPond-Book on Windows

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

>>> Sorry - probably busy with other stuff.  This may be what you want:
>>>
>>> C:\Program Files (x86)\LilyPondV2.18.0\usr\bin>python
>>> Python 2.4.5 (#1, Oct  6 2013, 18:41:07)
>>> [GCC 4.1.1] on mingw32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> exit(0)
>>> Traceback (most recent call last):
>>>  File "<stdin>", line 1, in ?
>>> TypeError: 'str' object is not callable
>>>>>>
>>
>> What I suspected.  Like the problem that gets a workaround in
>> LilyPond-book (and I am afraid that the workaround will likely break the
>> TEXINPUTS manipulation and thus does not lead to a working program),
>> this is pretty absurd.
>>
>> Instead of trying to find something nicer, like os.exit or sys.exit or
>> whatever, I think it would make more sense first to move to version 2.6
>> (which probably means updating to Jan's repository and/or merging it
>> into Graham's) and see how we fare there.  It's quite conceivable that
>> blunders like that are fixed in later versions.
>
> It would only need Graham's repo to be updated: I pull from there.
> For any updates to Gub or -extra, only Graham's repo is used.
>
> However, I have no idea how the update would be performed.
>
> Might be worth asking if there's a windows user with a later version
> of Python that could try exit(0).

The exit thing is more like a nuisance: it leads to misleading error
messages after an actual error is diagnosed.  The other thing is more
critical.  It may very well be that only our GUB-bootstrapped binaries
are affected.  Now if our current distributed version is 2.4.5, we'll
still get into the path

if (sys.platform == 'mingw32') and (sys.version_info < (2, 6)):
        ### use os.system to avoid weird sleep() problems on
        ### GUB's python 2.4.2 on mingw

So my first impulse would be to throw out the workaround for 2.4.2 that
has ceased to work out once we are meddling with TEXINPUTS and see what
happens.  However, it is a reasonable suspicion that we'll get back
whatever behavior led to the workaround to get introduced in the first
place.

The workaround is not all that old:

commit ab8dfc6e8f3de3cefc8fab09a4993acaec460720
Author: Graham Percival <address@hidden>
Date:   Thu Jan 12 05:57:59 2012 +0000

    lilypond-book: avoid subprocess for mingw


And the corresponding issue is
<URL:http://code.google.com/p/lilypond/issues/detail?id=1933>

So I have no idea what to do here.

The mentioned subprocess commit is in Graham's repository
<URL:https://github.com/gperciva/gub/commit/e3d46689d881045ceb2dbf31d7d4573709f781d8>
so the occurence of issue 1933 would suggest that this workaround can't
really be omitted for version 2.4.5.

Copying Graham and Jan in case they have some suggestion here.

-- 
David Kastrup