Reviving and modernising Capone

[ledurnan]

Hello maintainers,

I recently came across Capone and was impressed by the solid validation and integrity checks, along with optimisations like LedgerBalance. While there haven't been any updates for a while, this project surely has great potential for continued use and improvement.

I've taken the initiative to update the project to be compatible with modern Django, including dropping support for Django < 4.2 (3.2 LTS EOL is end Q1 2024). I have organised these into feature branches along with some other changes:

• Compatibility with modern Django https://github.com/ledurnan/capone/tree/feature/support-django-4.2-5.0-drop-legacy
• Parameterise db settings https://github.com/ledurnan/capone/tree/feature/parameterize-db-dotenv
• Time zone awareness. https://github.com/ledurnan/capone/tree/feature/tz-awareness
• Updating .gitignore https://github.com/ledurnan/capone/tree/feature/update-gitignore

I wanted to seek some guidance from you guys as maintainers before proceeding with pull requests.

Apart from providing a comprehensive rundown of changes alongside each request, are there any particular contribution guidelines or preferences on how you'd like these changes to be submitted?

[hrichards]

Hi, @ledurnan . Thanks for your interest! Let me get back to you after the Holidays, okay? We're in the middle of an upgrade process right now and might have some time to shepherd these upgrades. The specific upgrades you mentioned are on our radar, too.

[ledurnan]

Wonderful. Have a great new year 👍

[hrichards]

@ledurnan

I've looked at the branches on your fork, and I'm liking what I'm seeing. I'm okay proceeding with pull requests.

We don't have any strictures on this repo other than to make PRs from your fork against our main repo, create a detailed pull request description, and go through code review. Currently, promotion to PyPI happens on one of our internal pipelines (since we haven't set up our PyPI GitHub secrets here yet), FYI. We'll discuss specifics when we do PR review.

One request I'll be forced to make is that, when it comes to bumping the supported versions of Django, we produce versions with continuity among all LTSs, even ones that are EOL'd, that provide an upgrade path compatible with Django's deprecation cycle (i.e. the next version we cut should support 2.2 and 3.2 at least, the next 3.2 and 4.2, etc.). We have older systems that are using these versions of Django. It might be the best use of our time to just support several versions (or at least reference them in tox.ini) of Django at a time, as much as the codebase can reasonable bear. With smaller libraries like Capone, we've found that it's easy to keep the versions >=2.2 around for a long time: there's not that much churn in the APIs in those versions.

Once this repo is modernized, may I ask what you're going to do with it and what extra functionality you might want to add? Or do you just need the code's infrastructure modernized so that it works as-is with a modern Django project?