Re: Please test gub

[Knut Petersen]

On 09.02.19 13:57, David Kastrup wrote:
> Lukas-Fabian Moser <address@hidden> writes:
>
> > > > For more than 10 years gub/specs/lilypond.py used
> > > > /usr/bin/python. That means that during lilypond-test the system's
> > > > python interpreter is used as the interpreter for the musicxml2ly
> > > > script, not our own python in target/tools.  At some currently
> > > > unknown point in time musicxml2ly became incompatible to our python
> > > > 2.4. The hidden usage of the system's python masked that
> > > > incompatibility.
> > > >
> > > > With our python 2.4 musicxml2ly does not barf, it simply produces
> > > > garbage that lateron causes lilypond to fail.
> > The error was introduced when John Gourlay copied changes made by
> > Philomelos into the LilyPond git tree in commits
> >
> > 2ab5d80245dcab194daea64ec83ded3ec8252e51
> > dc90b895668826a09e06ad1ef94e5e90569a870c
> > da6591bef1cd9c684a9fb98f1563ea40c543ecdd
> >
> > in February 2016. Since these changes were copied as a bunch, one
> > would probably have to delve into Philomelos's git tree or analyze the
> > source directly.
> >
> > If you folks think it would be worth the effort, I could try to do this.
> I think it would make more sense updating Python to 2.7 in Gub.  With a
> few people currently looking at Gub, does that seem feasible?


Lukas thought of the following options

   1) make musicxml2ly work again (by changing the Python version used, or by 
fixing the problems with 2.4), or
   2) remove musicxml2ly from the distribution bundle, possibly
   2a) without replacement,
   2b) replaced by xml2ly

My comments:

   Option 1: 'fixing' musicxml to be compatible with python 2.4 is a waste of 
time. Updating python for all target platforms will take a lot of time. It's 
not clear if someone volunteers to do the job.
   Option 2a: not a real option, we need a working musicxml2ly (or replacement) 
for 'bin/gub lilypond-test' and 'bin/gub lilypond-doc'
   Option 2b: maybe that would work, but we still would see the need to update 
python.

We definitely want a tools::python-2-7, and this does not seem to be too 
complicated. On top of gub pull requests 53-60 we could use this python-2-7.py 
in gub/specs:

   from gub import target
   from gub import tools
   from gub.specs import python

   class Python_2_7__tools (python.Python__tools):
        source = 'https://www.python.org/ftp/python/2.7.15/Python-2.7.15.tgz'
        patches = []
        dependencies = ['autoconf', 'libtool']
        force_autoupdate = True
        make_flags = python.Python__tools.make_flags
        so_modules = ['_struct', 'datetime', 'itertools', 'time']
        def get_conflict_dict (self):
            return {'':        ['python-2-6'        , 'python'        ],
                    'doc':     ['python-2-6-doc'    , 'python-doc'    ],
                    'devel':   ['python-2-6-devel'  , 'python-devel'  ],
                    'runtime': ['python-2-6-runtime', 'python-runtime']}
        def patch (self):
            tools.AutoBuild.patch (self)
        configure_command = ('LD_LIBRARY_PATH=%(system_prefix)s/lib '
                             + tools.AutoBuild.configure_command)

It is something completely different to provide python for all target platforms.

For python 2.4.5 we use a lot of patches, most of those do not apply to 2.7.15. 
Do we still need the logic provided by those patches in python 2.7.15? Even if 
we reach a point that allows us to compile python 2.7.15 for all target 
platforms: We need people to test and debug the new installers.

To me it's pretty obvious that we need to provide a working guile 1.8 together 
with lilypond. But do we really need to provide python?

I tend to believe that the simplest, most resource-saving and most future-proof 
solution is to stop shipping python with lilypond installers and to simply 
instruct the users how to install python on the supported platforms.

Knut