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

[Namhyung Kim]

On Tue, Oct 01, 2024 at 06:47:47AM -0700, Ian Rogers wrote:
> 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.

Yeah I think it's time to consider sunsetting Python 2.  As Ian and
James said, it was bothering some development.

Andi, do you still use it with Python 2?  Or do you know anybody who
might suffer from this change?  Is it hard to upgrade the system?

I'm inclined to pick up this change unless there's a specific reason.

Thanks,
Namhyung