Comment by swiftcoder

15 days ago

9 months since the last major release definitely feels like a short time in which to declare time-of-death on an open source project

But if you set up dependabot and automerge some crap every couple of days your project will be very active!

Meanwhile my projects got marked as abandoned because those scanners are unaware of codeberg being a thing.

It’s been a lot longer than that. There was a reasonable sized effort to provide binaries via conda-forge but the users never came. That said, the PyPy devs were always a pleasure to work with.

  • > It’s been a lot longer than that.

    pypy 7.3.20, officially supporting python 3.11, was released in july 2025: https://pypy.org/posts/2025/07/pypy-v7320-release.html

    We're in March 2026. That's 9 months, which is exactly what GP stated.

    > There was a reasonable sized effort to provide binaries via conda-forge but the users never came.

    How is that in any way relevant to the maintenance status of pypy?

It is also lagging behind in terms of Python releases. They are currently on 3.11, which was released 3.5 years ago for mainline Python.

  • > It is also lagging behind in terms of Python releases.

    Which it has always been, especially since Python 3, as anyone who's followed the pypy project in the last decade years is well aware.

    • The problem is that it is lagging behind enough that it is falling out of the support window for a lot of libraries.

      Imagine someone releases RustPy tomorrow, which supports Python 2.7. Is it maintained? Technically, yes - it is just lagging behind a few releases. Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.

      2 replies →