Croniter (pour scheduler_events) sera supprimé le 15 mars 2025

pmz · Février 21, 2025, 3:11

Selon la doc :
« Une chaîne cron valide qui peut être analysée par croniter. »

La page du module sur pypi indique qu’il n’est pas conforme et qu’il sera supprimé le 15 mars 2025.
Je suppose que la partie pip install de l’installateur pourrait tomber en panne d’ici quelques semaines.

Le créateur, corpusops, un français, explique un peu plus sur sa page github.

J’ai informé la communauté Frappe sur le forum.

corentin · Février 21, 2025, 3:22

Bien vu, on avait déjà un peu réfléchi au sujet mais c’est bien de savoir qu’il y a une date fixée pour sa suppression. On va voir ce que fait la communauté Frappe d’ici là, sinon on trouvera et proposera une solution alternative rapidement.

github.com/corpusops/croniter

Hopefully not the end

opened 07:19PM - 17 Dec 24 UTC

latk

Earlier today, commit dbeeb1e5ba68a5e1fdee0f03791657e1302d6eea was pushed, which… declared the intention to end development of `croniter` and to maybe unpublish it in the course of 2025. This is due to the maintainers' worries about the EU Cyber Resilience Act, which will enter into force in phases between 2026-06-11 and 2027-12-11. Indeed, the CRA had received massive criticism when initially proposed, though subsequent lobbying by the Open Source community has reduced some of the impact. But as [Felix Reda discusses on the GitHub blog](https://github.blog/open-source/maintainers/what-the-eus-new-software-legislation-means-for-developers/), there are still many question marks about what the CRA will mean in practice, even if it does seem to exempt Open Source projects that aren't developed in the course of a commercial activity. It is completely understandable if you, @kiorky, don't want to bother about any of this. But it would be unnecessarily destructive to unpublish or otherwise remove a package with ~46 million monthly PyPI downloads ([source](https://pypistats.org/packages/croniter)). Please consider an alternative, like passing on control to another maintainer. I am not interested in doing this, but would commit to the bare minimum maintenance if the alternative is that this package enters the eternal /dev/null.