zulip/requirements
Robert Dyer 4d337cfc0d docs: Add dependency on sphinx_design.
Adds a dependency on "sphinx_design" for the docs system.  Allows
supporting tabs inside the developer documentatoin.  This is a
preparation commit for later refactoring of the OS-specific setup
documentation.
2024-03-15 17:37:34 -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: Move pip and zoneinfo forks to zulip organization. 2024-03-07 18:44:04 -05:00
dev.in requirements: Patch pip 20 to run on Python 3.12. 2024-03-01 17:38:08 -08:00
dev.txt docs: Add dependency on sphinx_design. 2024-03-15 17:37:34 -07:00
docs.in docs: Add dependency on sphinx_design. 2024-03-15 17:37:34 -07:00
docs.txt docs: Add dependency on sphinx_design. 2024-03-15 17:37:34 -07:00
mypy.in requirements: Upgrade Python requirements. 2024-01-29 10:41:54 -08:00
pip.in requirements: Fix Python 3.12 issue in pip._vendor.pkg_resources. 2024-03-15 17:37:11 -07:00
pip.txt requirements: Fix Python 3.12 issue in pip._vendor.pkg_resources. 2024-03-15 17:37:11 -07:00
prod.in kandra: Add a memcached exporter using bmemcached. 2024-02-23 13:32:04 -08:00
prod.txt requirements: Fix Python 3.12 issue in pip._vendor.pkg_resources. 2024-03-15 17:37:11 -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.