diff --git a/latest/development/contributing_guide.html b/latest/development/contributing_guide.html
index c6e4c274a4..84356e5152 100644
--- a/latest/development/contributing_guide.html
+++ b/latest/development/contributing_guide.html
@@ -166,6 +166,8 @@ on Windows is not officially supported.</p>
<p>Synapse can connect to PostgreSQL via the <a href="https://pypi.org/project/psycopg2/">psycopg2</a> Python library. Building this library from source requires access to PostgreSQL's C header files. On Debian or Ubuntu Linux, these can be installed with <code>sudo apt install libpq-dev</code>.</p>
<p>The source code of Synapse is hosted on GitHub. You will also need <a href="https://github.com/git-guides/install-git">a recent version of git</a>.</p>
<p>For some tests, you will need <a href="https://docs.docker.com/get-docker/">a recent version of Docker</a>.</p>
+<p>A recent version of the Rust compiler is needed to build the native modules. The
+easiest way of installing the latest version is to use <a href="https://rustup.rs/">rustup</a>.</p>
<h1 id="3-get-the-source"><a class="header" href="#3-get-the-source">3. Get the source.</a></h1>
<p>The preferred and easiest way to contribute changes is to fork the relevant
project on GitHub, and then <a href="https://help.github.com/articles/using-pull-requests/">create a pull request</a> to ask us to pull your
@@ -222,6 +224,10 @@ to check that your contributions render correctly. The docs are written in
<p>Some documentation also exists in <a href="https://github.com/matrix-org/synapse/wiki">Synapse's GitHub
Wiki</a>, although this is primarily
contributed to by community authors.</p>
+<p>When changes are made to any Rust code then you must call either <code>poetry install</code>
+or <code>maturin develop</code> (if installed) to rebuild the Rust code. Using <a href="https://github.com/PyO3/maturin"><code>maturin</code></a>
+is quicker than <code>poetry install</code>, so is recommended when making frequent
+changes to the Rust code.</p>
<h1 id="8-test-test-test"><a class="header" href="#8-test-test-test">8. Test, test, test!</a></h1>
<p><a name="test-test-test"></a></p>
<p>While you're developing and before submitting a patch, you'll
@@ -270,7 +276,7 @@ working directory. Typically, this ends up being <code>_trial_temp/test.db</code
<p>The database file can then be inspected with:</p>
<pre><code class="language-sh">sqlite3 _trial_temp/test.db
</code></pre>
-<p>Note that the database file is cleared at the beginning of each test run. Thus it
+<p>Note that the database file is cleared at the beginning of each test run. Thus it
will always only contain the data generated by the <em>last run test</em>. Though generally
when debugging, one is only running a single test anyway.</p>
<h3 id="running-tests-under-postgresql"><a class="header" href="#running-tests-under-postgresql">Running tests under PostgreSQL</a></h3>
diff --git a/latest/development/dependencies.html b/latest/development/dependencies.html
index 75cda34011..7559d61c5c 100644
--- a/latest/development/dependencies.html
+++ b/latest/development/dependencies.html
@@ -242,6 +242,20 @@ context of poetry's venv, without having to run <code>poetry shell</code> before
<h2 id="reset-my-venv-to-the-locked-environment"><a class="header" href="#reset-my-venv-to-the-locked-environment">...reset my venv to the locked environment?</a></h2>
<pre><code class="language-shell">poetry install --extras all --remove-untracked
</code></pre>
+<h2 id="delete-everything-and-start-over-from-scratch"><a class="header" href="#delete-everything-and-start-over-from-scratch">...delete everything and start over from scratch?</a></h2>
+<pre><code class="language-shell"># Stop the current virtualenv if active
+$ deactivate
+
+# Remove all of the files from the current environment.
+# Don't worry, even though it says "all", this will only
+# remove the Poetry virtualenvs for the current project.
+$ poetry env remove --all
+
+# Reactivate Poetry shell to create the virtualenv again
+$ poetry shell
+# Install everything again
+$ poetry install --extras all
+</code></pre>
<h2 id="run-a-command-in-the-poetry-virtualenv"><a class="header" href="#run-a-command-in-the-poetry-virtualenv">...run a command in the <code>poetry</code> virtualenv?</a></h2>
<p>Use <code>poetry run cmd args</code> when you need the python virtualenv context.
To avoid typing <code>poetry run</code> all the time, you can run <code>poetry shell</code>
@@ -330,6 +344,11 @@ installed <code>poetry</code> with <code>pipx</code>, try <code>pipx runpip poet
<p>Poetry caches a bunch of information about packages that isn't readily available
from PyPI. (This is what makes poetry seem slow when doing the first
<code>poetry install</code>.) Try <code>poetry cache list</code> and <code>poetry cache clear --all <name of cache></code> to see if that fixes things.</p>
+<h2 id="remove-outdated-egg-info"><a class="header" href="#remove-outdated-egg-info">Remove outdated egg-info</a></h2>
+<p>Delete the <code>matrix_synapse.egg-info/</code> directory from the root of your Synapse
+install.</p>
+<p>This stores some cached information about dependencies and often conflicts with
+letting Poetry do the right thing.</p>
<h2 id="try---verbose-or---dry-run-arguments"><a class="header" href="#try---verbose-or---dry-run-arguments">Try <code>--verbose</code> or <code>--dry-run</code> arguments.</a></h2>
<p>Sometimes useful to see what poetry's internal logic is.</p>
|
