Check if a user's package versions are consistent with those specified in requirements

[kaustubh-nair]

Users running the development version of the app might have outdated packages if the packages are upgraded in subsequent commits.
While starting up, ZT should check if the package versions are the same, and display a warning/error if there's some mismatch between the installed and required versions.

[sundargs2000]

@zulipbot claim

[neiljp]

@sundargs2000 Thanks for taking the initiative to look into this issue 👍

While this is marked as a good first issue - and it doesn't require heavy understanding of the project internals to explore - there are a few points to be aware of:

• If we implemented the check so as to be present in the published version, we would want it to be as close as possible to a no-op when things were OK, to minimize startup time (ie. to not impact users not in a development environment, or dev users on one branch)
• While our requirements.txt and Pipfile should be up to date, we mainly publish to PyPI so setup.py would be the preferred source of truth (also they have other dependencies, which we don't strictly need for purely running ZT)
• We'd need to make sure we have the list of dependencies available at run-time, which I'm not sure if we do?
• In May we added a development alternative to use a makefile to set up the venv; this doesn't resolve the issue through checking at app startup, though each make invocation should ensure this as a pre-requisite.

As above, the makefile approach doesn't resolve this issue as originally specified, so there is still an option to follow-through with that, but if included in the distributed source there are quite a few extra constraints to consider. I appreciate you've worked on the PR and you're welcome to continue with that - noting that we may have a high threshold to merge it. I'd suggest you also explore the current makefile option in your development environment, as we'd also welcome feedback on that, particularly if you used a different method of installation previously.

[sundargs2000]

Hey @neiljp. Thank you for the feedback.

• So about making it no-op, does seem very tough as the functions I have used are what pip uses as well during installation. I don't have complete clarity and will look into it.
• Setup.py would be a better source of truth. Also, I need to just check testing_deps, linting_deps and dev_helper_deps since running with inconsistent install_requires gives an error. This warning is mainly aimed at developers who would pull the repository and not install through pip.
  I will look into whether there is any other better method. Any suggestions would be helpful as well. Thank you!

[neiljp]

@sundargs2000 Just checking in and mentioning that you are welcome to work on other issues if this is blocking you, as well as giving a little extra clarification below.

• Re no-op, as long as we use the same versioning style, testing for git or +git in the version string should be reasonable. Wrapping that in a small function in the version file as is_development_version seems useful - we could use that to show extra text saying so in the about dialog box too.
• We should only need to check the runtime deps, not testing/linting/dev_helper, as they shouldn't be loaded at runtime - unless you can find an exception to that rule.

To reiterate the original description: the kinds of situation we're working to resolve (if not fixed by make now) are where a developer either installs a wrong version of a package manually and then ZT misbehaves in their virtual environment, or similarly they switch branch and the dependency requirements don't match what's installed. This situation shouldn't (often) arise with non-development environments.

[sundargs2000]

@neiljp Thank you for the clarity. I have my exams, but will update the PR ASAP.