Most libraries are inactive

[jorenham]

While looking at some of the libraries, I noticed that many of them haven't been active for years, and some archived.

I checked all of them. I listed the ones with >1 year since the last PyPi release, and no commit activity, and the year since the last (non-trivial) commit:

General

14 / 23

• fn.py "maintaned" fork - a minimal release in 2023, but the release before that was in 2027 (see the changelog)
• PyFunctional - 2021 (some PR's were merged in Sep 2023, then radio silence again)
• hask - 2015
• OSlash - 2020
• Effect - 2022
• Underscore.py - 2018
• fnc - 2021 (some config tweaks in Oct 2023, then radio silence again)
• Flupy - 2022
• Phi - 2018
• pyramda - Archived by the owner on Sep 5, 2023
• PyMonad - 2021
• unpythonic - 2022
• pyMonet - 2020
• pyeffects - 2022 (some dependabot and other trivial PR's are spuriously merged, but the last release was in 2022, and the CI appears broken)

Return types

2 / 5

• Option - 2022
• Safetywrap - 2020

Immutable / persistent data structures

4 / 6

• Discodb - 2015
• Funktown - 2015
• Amino - 2019
• Pysistence - 2011, repo is gone

Pattern matching

3 / 4

• pampy - 2022
• python-pattern-matching - 2021
• patmat - 2016

Tran~s~ducers

2 / 2 (!)

• Tranducers-Python - archived by the owner on Jun 3, 2023
• Transducers - 2017

Reactive programming

2 / 3

• RxPy - 2022 (no reactions on issues either)
• sodium-python - 2022 (except for 2 commits and minimal release in July, 2023)

Lenses and declarative data manipulations

0 / 2

Other / specialized

4 / ~8~7

• ~chainable~ Flupy - 2022 (fyi, it's renamed to Flupy, which is also in the General category)
• ADT - 2021
• sumtypes - 2021
• python-mini-lambda - 2020

Languages

5/8

• Mochi - 2016
• ~Tydy~ typy - 2018
• dg (aka dogelang) - 2020
• pixie - 2017
• Pycket - 2021

---

Removing these would not be a good idea IMHO -- clearly marking them as inactive, unmaintained, or abandoned would be more informative.

It's truly sad to see so many of these (potentially) awesome projects end like this...

[c00kiemon5ter]

Functional libraries don't need constant tweaking and updates. They become stable and reusable and that is a good thing.

Of course that is not true for all of the libs you've listed, but also don't think that the date on the latest commit gives you the actual state of a library.

[sfermigier]

@jorenham : thanks for your research. Indeed, some categories are really obsolete (e.g. pattern matching), some projects are truly dead (e.g. when marked as archived by their author), some projects were obviously experiments that didn't lead to sustainable use, and some lost (sadly) their maintainer's attention. But as @c00kiemon5ter wrote, some projects are also mature enough to not need constant tweaking and updates, only the occasional compatibility update release. So, indeed, additional comments might be useful, on a case by case basis.

[jorenham]

@c00kiemon5ter I agree that the definition of abandoned project which I stated, is rather arbitrary:

I listed the ones with >1 year since the last PyPi release, and no commit activity, and the year since the last (non-trivial) commit

@sfermigier, I understand that several of these packages are simple "done". However, my main concern with lack of activity, is that it correlates with the lack of support for newer version of Python.

Specifically, many of these inactive projects rely on the legacy setup.py build system, instead of using the recommended pyproject.toml one. This can be problematic on Python 3.12, because it doesn't bundle setuptools anymore and removed distutils.

Another issue is that several of these inactive projects have confirmed bugs that aren't addressed by the developers, or the PR's with fixes aren't merged. For instance, this is (currently) the case with RxPY. Considering the amount of stars, I can imagine this leading security issues in e.g. web applications that rely on it.

But even if there currenly are no reported bugs, the possibility of finding one will always exist. It is problematic if there are no developers that are willing to address this when they come up.

This is why I believe that when advertising open-source libraries, their "state" or "health" should be also explicitly presented. The last development activity plays an important role in determining this, but other factors should also be considered when applicable.

[wolph]

Functional libraries don't need constant tweaking and updates. They become stable and reusable and that is a good thing.

As a maintainer of many packages and libraries that don't all get regular updates I think there's an important caveat to consider here. A package can indeed be "done" without requiring many updates, but if the library has many opened issues than it's obviously not done or it's not maintained.

Having a library without updates for over 2 years is not always an issue, but it is if there are many open issues without a reply