zulip/requirements
Anders Kaseorg 784622ee5d requirements: Upgrade Python requirements. 2023-06-20 16:17:55 -07:00
..
README.md docs: Document how to use a self-modified dependency with Zulip in dev. 2023-04-13 15:58:03 -07:00
common.in requirements: Switch to released jsx-lexer fix (same code). 2023-05-23 13:47:36 -07:00
dev.in requirements: Switch to released coverage fix. 2023-05-29 14:41:20 -07:00
dev.txt requirements: Upgrade Python requirements. 2023-06-20 16:17:55 -07:00
docs.in requirements: Upgrade Python requirements. 2023-03-05 14:46:28 -08:00
docs.txt requirements: Upgrade Python requirements. 2023-06-20 16:17:55 -07:00
mypy.in requirements: Upgrade Python requirements. 2022-11-03 14:08:58 -07:00
pip.in requirements: Upgrade Python requirements. 2021-05-07 22:42:39 -07:00
pip.txt requirements: Upgrade Python requirements. 2023-06-20 16:17:55 -07:00
prod.in
prod.txt requirements: Upgrade Python requirements. 2023-06-20 16:17:55 -07:00

README.md

The dependency graph of the requirements is as follows:

dev +-> prod +-> common
+
|
v
docs,pip

Of the files, only dev and prod have been used in the install scripts directly. The rest are implicit dependencies.

Steps to update a lock file, e.g. to update ipython from 5.3.0 to latest version:

  1. Remove entry for ipython==5.3.0 in dev.txt.
  2. Run ./tools/update-locked-requirements, which will generate new entries, pinned to the latest version.
  3. Increase PROVISION_VERSION in version.py.
  4. Run ./tools/provision to install the new deps and test them.
  5. Commit your changes.

Testing custom modifications of a dependency

When working on Zulip, sometimes it is necessary to also make modifications to a dependency (either to add a feature that we will rely on, or to fix a bug that needs to be fixed for the intended changes to work in Zulip) - with the idea that eventually they will be merged upstream and included in an official release.

That process can take time however, and sometimes it'd be good to be able to create and test your Zulip changes on top of changes to the upstream package, without waiting for the potentially lengthy code review and release process of the upstream dependency.

You can do this forking the upstream project, making the changes on a branch in your fork, and then replacing the package's entry in dev.in or prod.in with an appropriate GitHub link to the branch with your modifications. The files have various examples of how this should be done, but essentially you will add an entry looking like this:

https://github.com/<your GitHub>/<package name>/archive/<commit hash>.zip#egg=<package name>==<version>+git

After that, you can follow the above process involving ./tools/update-locked-requirements and the following steps to have the modified package installed in your dev environment, where it can be used for testing.