2023-24 dependency review

[micahellison]

Motivation

This dependency review is a process I started a few years ago (#1052, #1433) in part to make sure our dependencies aren't getting out of date. I've been hoping to do this around once a year, though this year-and-a-half interval seems fine so far, especially considering all the info we regularly get through renovate and poetry.

For each dependency, I look at their release history and open issues, while also documenting trouble we've had with it or goals for working with it differently. Doing this formally helps prevent surprises, especially ones that emerge from the sheer between new Python versions and old code rot. I'll go through this process by responding to this issue in the coming weeks or possibly months.

As usual, I'll be ignoring dev dependencies in this issue.

If you have any thoughts about the future of any of these dependencies in jrnl, please add them here. Though if there are any actions to take on this discussion, let's spin those off into new issues.

Dependency Checklist

This is from the pyproject.toml file on the develop branch as this issue's creation date.

Non-dev dependencies

• colorama = ">=0.4" # https://github.com/tartley/colorama/blob/master/CHANGELOG.rst
• cryptography = ">=3.0" # https://cryptography.io/en/latest/api-stability.html
• keyring = ">=21.0" # https://github.com/jaraco/keyring#integration
• parsedatetime = ">=2.6"
• python-dateutil = "^2.8" # https://github.com/dateutil/dateutil/blob/master/RELEASING
• pyxdg = ">=0.27.0"
• "ruamel.yaml" = ">=0.17.22"
• rich = ">=12.2.0, <14.0.0"

Dayone-only deps

• tzlocal = ">=4.0" # https://github.com/regebro/tzlocal/blob/master/CHANGES.txt

[micahellison]

We've discussed replacing colorama with rich for a year or two now. I've just filed an issue on the specifics #1805.

[micahellison]

cryptography has worked well for us. Even though its sub-dependency issue is keeping us from being able to support Python 3.12 so far, I'm optimistic that they'll have it resolved soon. Moreover, I don't think there are really any viable alternatives. If we end up using another library for encryption, it would probably be to support new encryption formats, rather than take a different approach to our current encryption process.

[micahellison]

keyring is working well, as always. I don't see any major problems in their issues, and it is working well for me in Python 3.12.

[micahellison]

ruamel.yaml remains functional and very actively maintained. We had a little hiccup with its subdependency ruaml.yaml.clib but it was due to their CI system, and the maintainer resolved ASAP after their CI system fixed things on their end.

When there's more time and energy, I plan to use its more advanced YAML modification features for the config issues #1102 and #1068.