Open jorenham opened 8 months ago
c00kiemon5ter
commented
8 months ago 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
commented
8 months ago @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
commented
8 months ago @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
commented
8 months ago 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
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
Return types
2 / 5
Immutable / persistent data structures
4 / 6
Pattern matching
3 / 4
Tran~s~ducers
2 / 2 (!)
Reactive programming
2 / 3
Lenses and declarative data manipulations
0 / 2
Other / specialized
4 / ~8~7
Flupy, which is also in the General category)Languages
5/8
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...