User is always asked to update when config resembles JSON

[kaylee-kiako]

Diagnostic output

jrnl: v4.1
Python: 3.11.9 (main, Apr  2 2024, 08:25:04) [GCC 13.2.0]
OS: Linux 6.6.32

Current Behavior

Whenever the config file resembles JSON, the user is prompted to update, regardless of if version is set.

Expected Behavior

As YAML is a superset of JSON (so this is a valid config), and "version": "v4.1" is set, I would expect not to be prompted to update.

Repro Steps

1. Set your config to a JSON-style YAML file. For reference, the following is my config. (Since it was generated by my operating system, it hasn't been given any readable formatting.)

{"colors":{"body":"none","date":"black","tags":"yellow","title":"cyan"},"default_hour":9,"default_minute":0,"editor":"hx","encrypt":false,"highlight":true,"indent_character":"|","journals":{"default":{"journal":"~/Documents/jrnl/journal.txt"},"food":{"journal":"~/Documents/jrnl/food.txt"}},"linewrap":79,"tagsymbols":"#@","template":false,"timeformat":"%F %r","version":"v4.1"}

2. Run jrnl.

Debug output

[13:46:01] DEBUG    Logging start                                                     main.py:32
           DEBUG    Parsed args:                                                      main.py:42
                    Namespace(debug=True, preconfig_cmd=None, postconfig_cmd=None,
                    filename=None, template=None, on_date=None,
                    today_in_history=False, month=None, day=None, year=None,
                    start_date=None, end_date=None, contains=None, strict=False,
                    starred=False, tagged=False, limit=None, excluded=[], edit=False,
                    delete=False, change_time=None, export=False, tags=False,
                    short=False, config_override=[], config_file_path='', text=[],
                    exclude_starred=False, exclude_tagged=False)
           DEBUG    Reading configuration from file                                install.py:91
                    /home/kaylee/.config/jrnl/jrnl.yaml
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃  Welcome to jrnl v4.1!                                                           ┃
┃                                                                                  ┃
┃  It looks like you've been using an older version of jrnl until now. That's      ┃
┃  okay - jrnl will now upgrade your configuration and journal files. Afterwards   ┃
┃  you can enjoy all of the great new features that come with jrnl 2:              ┃
┃                                                                                  ┃
┃  - Support for storing your journal in multiple files                            ┃
┃  - Faster reading and writing for large journals                                 ┃
┃  - New encryption back-end that makes installing jrnl much easier                ┃
┃  - Tons of bug fixes                                                             ┃
┃                                                                                  ┃
┃  Please note that jrnl 1.x is NOT forward compatible with this version of jrnl.  ┃
┃  If you choose to proceed, you will not be able to use your journals with        ┃
┃  older versions of jrnl anymore.                                                 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃  The following journals will be upgraded to jrnl v4.1:  ┃
┃  default -> /home/kaylee/Documents/jrnl/journal.txt     ┃
┃  food    -> /home/kaylee/Documents/jrnl/food.txt        ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Continue upgrading jrnl? [y/N] N
┏━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃  jrnl was NOT upgraded  ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━┛

Other Information

It appears the culprit is is_old_version, which only checks if the config is JSON without considering the version field.

[micahellison]

Thanks for filing this, @kaylee-kiako. Nice find, and I agree with your analysis.

If anyone would like to submit a PR to fix this, I think a resolution should:

• Update is_old_version to first check if the version field exists, and if it does, return true if it's less than 2.0. If there is no version, run that json check as it does currently.
• Update tests as necessary