Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere

Resent. Not yet sent from ML but later one was sent.
Adding @freebsd.org address of Enji, as gmail does not accept mails
from dec.sakura.ne.jp, which has neither DKIM functionality nor SPF
record.

On Thu, 10 Aug 2023 16:32:32 -0700
Enji Cooper <yaneurabeya@gmail.com> wrote:

> > On Aug 10, 2023, at 4:00 PM, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> > 
> > On Thu, 10 Aug 2023 18:09:54 -0400
> > Charlie Li <vishwin@freebsd.org> wrote:
> > 
> >> Enji Cooper wrote:
> >>> Hmm… All lang/python27 requiring ports should be marked BROKEN and
> >>> removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/.
> >> We can't entirely do that yet. Unfortunately, moinmoin, original mailman
> >> and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this.
> >> It was the case that Chrom{e,ium} and qt-webengine still had Python 2
> >> build bits but they've since migrated off.
> >> 
> >> --
> >> Charlie Li
> >> …nope, still don't have an exit line.
> > 
> > Can lang/tauthon used instead of lang/python27?
> > It's a fork of python27 and maintained (slowly) like [1].
> 
> Lang/tauthon probably could be used instead.

Even if original upstream is abandoned, maintained fork would better be
allowed. If tauthon can be considered "well maintained", consumers of
python27 which is enough compatible with tauthon can switch to tauthon
and un-deprecated.


> > I don't use python nor tauthon directly, though.
> > I dislike languages killing backward compatibility... :-(
> > 
> > I love C as even recent llvm/clang has an ability to compile K&R
> > codes, if proper options are set. This is how ALL computer languages
> > SHALL BE.
> 
> The problem that python2 -> python3 was trying to solve was multifold: there were a variety of issues with the language, as defined in python2, which made the syntax changes going from 2 to 3 necessary.
> 
> That being said, the whole “python2 is going away in 2020” was advertised well in advance (several years). If projects hadn’t done the work of getting off python2 by 2020, it’s their fault in not prioritizing that effort.
> 
> The problem with packages like MoinMoin, etc, is that unless they’re completely isolated (vendor and provide all of their dependencies), they are likely developing pieces of software on vulnerable versions of third-party packages since many packages started yanking python2 support in the past couple years. Yanking python2 support allows third-party projects to be developed with more modern syntax niceties like the walrus operator, type hints, asyncio, etc. It’s not logical for pieces of software to not improve.
> 
> Python is not C or Perl; the transition from 2 to 3 was particularly painful, but the changes were based on development that was over a decade in the making.

If I'm the project owner of python, I would have been decided to
abandon python and switch to different name because of backward
incompatibility. But unfortunately, they didn't do so.

If the software itself runs on python, I think you're completely right.
It should be rewritten.

But for softwares which uses python only on build time, staying on
python27 should be allowed.
In small projects, if the person who built the building environment
retired from the project and noone else can understand / maintain the
build system, the only selection is "stay there until someone who can
construct new build environment pops in". This could happen here and
there, unfortunately.

For example,

 *Consider python27 and required py-* as bootstrapping tool.
 *Build python27 and required py-* everytime the port is built
  and cleanup afterwards, INSIDE PORTS WORKDIR.
 *python27 and required py-* are listed in distinfo of each port which
  requires python27 on build time only.

would allow lang/python27 to be deleted, if possible.


> 
> Cheers,
> -Enji


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>