Adds a GH workflow that will run `make compile-requirements` and create
a PR for it and overhauls the requirements README with info on how to
use the new workflows.
README changes:
- Group the workflow/makefile info under a new heading
- Switch to imperative for headings
- Move "Upgrade all dependencies" to end of list (uncommon for people to
actually need this command, I suspect)
- Add "Add a dependency"
- Preamble about .in and .txt files and Mac vs. Linux, as well as about forks
Also, some style fixes to upgrade-one-python-dependency GH workflow:
- Fix indentation in inputs block
- Remove "-workflow" from job name (probably copied from another workflow)
- Wrap a long line
We have a few situations where requirements files can become
inconsistent or cause unnecessary review churn in later `make upgrade`
runs either due to manual editing, inconsistent environments, or
incorrectly specified git dependencies. This will produce a failing
check for any PR that does not produce a clean run of `make
compile-requirements` on Linux.
Addresses https://github.com/openedx/edx-platform/issues/31372
This adds a Make target that should simplify the common task of
upgrading a single dependency. Sometimes people manually edit the pin
files, which we would like to avoid; hopefully this will make it
easier for them to do the right thing.
The GitHub workflow should also make it easier for people on Mac to
recompile requirements in a Linux environment, reducing the number of
times spurious dependency changes show up in the pin files (due to
OS-dependent requirements.)
Also, separate upgrade/downgrade instructions and simplify the latter.
(Min constraints are rare and we usually move beyond them quickly.)
This change embraces persistent min-version dependencies, which can
simply be ratcheted up over time, or safely removed in time because IDAs
rarely have a large dependency downgrade.
Some dependencies are already encoded with a min-version constraint, which
makes the previous instructions confusing. There was also a very minor
issue in which the temporary constraint line was adding a spurious
`-c constraints.txt` to the committed changes, even though the constraint
itself was not being committed.
This change inspired by discussion on PR #27506.
