Re: [PATCH v1 1/2] perf python: Remove python 2 scripting support

[Ian Rogers]

On Tue, Oct 1, 2024 at 4:22 AM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, Sep 30, 2024 at 02:26:47PM -0700, Namhyung Kim wrote:
> > On Thu, Sep 19, 2024 at 06:45:23AM +0200, Ian Rogers wrote:
> > > On Thu, Sep 19, 2024 at 3:29 AM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Thu, Sep 19, 2024 at 12:54:17AM +0200, Ian Rogers wrote:
> > > > > Python2 was deprecated 4 years ago, remove support and workarounds.
> > > >
> > > > Nacked-by: Andi Kleen
> > > >
> > > > I don't see any advantages of breaking perfectly fine existing setups
> > > > for no benefits.
> >
> > Well, I think the benefit is in the maintenance.  The EOL of Python 2
> > was 2020/1/1 [1] and we are targeting this release (v6.13) in 2025.  So
>
> AFAIK it's still widely used, and supported by third parties. And even
> if not it's not that the python usage in perf needs any external support.
>
> In Linux deprecation is generally tied to nobody using something
> anymore, and that is clearly not the case here.
>
> > I think it's reasonable to consider removing Python 2 support now.
>
> That's code that practically never changes, so I don't see any
> maintenance benefit. I mean it needs to be compile tested / perf tested,
> but Arnaldo's container collection will do that practically
> for free.

So of the Linux distributions that supported Python 2, the versions
that did stopped being supported in June this year.
The hypothetical person who cares about python 2 support needs to be
building their own kernel tree, they've had to upgrade GCC, etc. but
GCC isn't particularly relevant here.
The hypothetical person wants to build on their unsupported
distribution the latest and greatest perf tool. Now the perf build has
required python 3.6 for json events for 2.5 years. So this
hypothetical person who wants the latest perf tool on their
unsupported system must not care about json events and metrics but
does care about python 2 integration for scripting.
I really don't see such a person existing and if they did they can:
1) install python3
2) use an older perf tool

There is a constant cost in the code base trying to know whether
python means 2 or 3. Keeping dead code around at the very least
creates poor code coverage numbers. We want to add to the python entry
points into the code with parse_events. We want to make python a
dlopen dependency (as done in uftrace) rather than something that's
linked against. In other words python development is somewhat active
and trying to carry around python 2 support when no one we can name
wants it is just burdening us down, costing us in time and code
coverage for no gain.

Thanks,
Ian