mirror of https://github.com/zulip/zulip.git
docs: Refresh docs on updating python requirements.
Those docs were outdated and no longer represantative of how things work. upgrade-python-dependencies and unupgradable.json are no longer a thing, so the entire paragraph about them should be removed. Then the requirements/README.md file is refreshed a bit to be more accurate.
This commit is contained in:
parent
f5e95c4fc1
commit
65f7231dd3
|
@ -201,29 +201,6 @@ highlighting. The system is largely managed by the code in
|
|||
See the [README][requirements-readme] file in `requirements/` directory
|
||||
to learn how to upgrade a single Python package.
|
||||
|
||||
For batches upgrades of many or all Python dependencies, we have the
|
||||
script `./tools/upgrade-python-dependencies`. This script will update
|
||||
the outdated packages one at a time, create a commit for each package
|
||||
if the backend tests pass and pushes the working branch to your GitHub
|
||||
fork. Make sure to enable [caching][caching] your GitHub credentials
|
||||
so that Git won't keep asking you for it during each push. When a
|
||||
package cannot be upgraded due to test failures or other issues the
|
||||
error message would be stored in the file
|
||||
`var/log/python_dependency_upgrade/<package_name>`. We also maintain a
|
||||
list of packages that cannot be upgraded in
|
||||
`requirements/unupgradable.json`. The script won't attempt to upgrade
|
||||
the packages in this list. Most of these packages requires changes in
|
||||
upstream for us to upgrade them. The remaining ones are usually
|
||||
packages that involves significant changes in our codebase. The
|
||||
packages that are easier to upgrade by making some minor changes in
|
||||
our codebase won't make it to this list. Only issues are created for
|
||||
them in GitHub with the label `area: dependencies`. Keep in mind that
|
||||
this script would take a significant amount of time to complete. Our
|
||||
recommended way of running this script is in a cloud VM which has
|
||||
super fast internet. You can use tmux or screen to make sure that the
|
||||
[script keeps running even if you get disconnected][stack-overflow]
|
||||
from the SSH session.
|
||||
|
||||
[mypy-docs]: ../testing/mypy.md
|
||||
[requirements-readme]: https://github.com/zulip/zulip/blob/master/requirements/README.md#requirements
|
||||
[stack-overflow]: https://askubuntu.com/questions/8653/how-to-keep-processes-running-after-ending-ssh-session
|
||||
|
|
|
@ -11,12 +11,9 @@ mypy,docs
|
|||
Of the files, only dev, prod, and mypy have been used in the install
|
||||
scripts directly. The rest are implicit dependencies.
|
||||
|
||||
common and dev are locked.
|
||||
|
||||
Steps to update a lock file, e.g. to update ipython from 5.3.0 to 6.0.0 in
|
||||
common.in and propagate it to dev.txt and prod.txt:
|
||||
0. Replace `ipython==5.4.1` with `ipython==6.0.0` in common.in.
|
||||
1. Run `./tools/update-locked-requirements`.
|
||||
Steps to update a lock file, e.g. to update ipython from 5.3.0 to latest version:
|
||||
0. Remove entries for `ipython==5.4.1` in dev.txt and prod.txt.
|
||||
1. Run `./tools/update-locked-requirements`, which will generate new entries, pinned to the latest version.
|
||||
2. Increase `PROVISION_VERSION` in `version.py`.
|
||||
3. Run `./tools/provision` to install the new deps and test them.
|
||||
4. Commit your changes.
|
||||
|
|
Loading…
Reference in New Issue