I think along with an hypothetical version 1.0 (and maybe attracting new users and developers) we could clean/tidy a few other things as well, write some more developer documentation, where to look up how ActivityPub works, write down a few things from the video tour through the codebase as text, write some glossary about the terminology. Do a bit of cleanup work and delete old and unused CSS classes. Suppress the confusing exceptions in the maintenance task and fix the timeouts. Maybe gather stats from Celery and tie it into the admin interface.

  • Oskar@piefed.social
    link
    fedilink
    English
    arrow-up
    4
    ·
    13 days ago

    Some suggestions that have worked for me for keeping a code base consistent with multiple developers working on it, and avoiding the technical debt of different styles:

    • decide on formatting
    • decide on linter and rules
    • use pre-commit rules for the above

    ruff is quick enough to use pre-commit. It also give helpful hints when linting, like app/utils.py:924:16: E712 Avoid equality comparisons to False; use if not Community.banned: for false checks

    Formatting the codebase is probably best done in a single merge commit. Fixing linter issues can be done whenever a file is worked on.

    I’ve worked on Flask projects and switching to Poetry helped us with Flask plugin incompatibilities. At least it was detected by Poetry when adding them, not at runtime (that was what happened when Pip was used). Today I’d pick UV för dependency management.