lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: switching to Python 3.x


From: Jonas Hahnfeld
Subject: Re: switching to Python 3.x
Date: Sun, 26 Jan 2020 15:04:04 +0100
User-agent: Evolution 3.34.3

Am Sonntag, den 26.01.2020, 14:53 +0100 schrieb Han-Wen Nienhuys:
> On Mon, Jan 6, 2020 at 8:21 PM David Kastrup <
> address@hidden
> > wrote:
> > > > 1) Adapt the build system to find and require Python 3.
> > > > patch:
> > > > https://codereview.appspot.com/545370043
> > > > 
> > > > 
> > > > 2) The largest part of the switch is running 2to3 which is now able to
> > > > handle the rest of the conversion automatically. For reference, changes
> > > > for current 'master' are here:
> > > > https://codereview.appspot.com/573340043
> > > > 
> > > > 
> > > > 3) Fix-up two places in the scripts afterwards:
> > > > 3a) Remove the call to sys.setdefaultencoding which doesn't exist in
> > > > Python 3.x (and is only available right now because of a dirty hack).
> > > > 3b) Replace cgi.escape by html.escape. While not strictly needed, I
> > > > think we should include this change because they removed cgi.escape in
> > > > Python 3.8 after only deprecating it in Python 3.2. The replacement
> > > > html.escape is only available since that Python 3.2, so we can't do
> > > > this before switching.
> > > > patch:
> > > > https://codereview.appspot.com/561270043
> > > > 
> > > > 
> > > > 
> > > > One point worth discussing is the future minimum version of Python 3.x.
> > > > In the patch, I'm proposing Python 3.5 because it will allow us to
> > > > address a few deprecation warnings, especially about module 'imp'.
> > > > It should be available in most Linux distributions:
> > > >  * CentOS 7 provides Python 3.6 since some minor releases
> > > >  * Debian 9 (Stretch) has packages for Python 3.5, Debian 10 (Buster)
> > > > even for Python 3.6
> > > >  * Ubuntu 16.04 LTS has Python 3.5, version 18.04 LTS has Python 3.6
> > > > 
> > > > Debian 8 (Jessie) only has Python 3.4, but even its LTS support will
> > > > end next June (2020-06). Would it be acceptable to drop support for
> > > > this distribution building 'master'?
> > > > On the GUB side, I already added a spec for Python 3.7.4 (also for
> > > > Windows via binary packages) and this worked successfully in September.
> > > > Is there a major distribution missing that doesn't provide at least
> > > > Python 3.5?
> > > > 
> > > > Let me know what you think!
> > > 
> > > So far, I've only received a single (positive) response off-list and a
> > > bit of feedback on the posted patches. What do others think?
> > > To make this explicit: The proposal is to drop support for Python 2
> > > (now EOL), requiring everyone wishing to build LilyPond 'master' to
> > > have an appropriate version of Python 3 available. This should be
> > > sufficiently easy (see above), but I'd like to have consensus on this.
> > 
> > When we switch over GUB, we also need to switch over the 2.20 branch.
> > It's not just master that is affected.
> 
> But we only need to switch GUB to py3 when we package 2.21 with GUB.
> We could kick this problem down the road until we really need a GUB
> build of 2.21, which may well be a few months in the future, or never
> if we decide to move to some other packaging mechanism (cf. the
> discussion of Docker/Windows)
> 
> I don't think it's reasonable for us to ask Jonas to also package
> python3 for GUB as a precondition to getting his patches in.

I'm going to start by quoting myself:
> > > > On the GUB side, I already added a spec for Python 3.7.4 (also for
> > > > Windows via binary packages) and this worked successfully in September.
So even if you don't think it's needed, I already did. Even though I
would fully support switching away from GUB!

What David is concerned about (as far as I understand) is that we need
to modify the spec for LilyPond to require the new python3 package as a
dependency. This will (obviously) not work for packaging 2.20.

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]