For some reason sphinx is being listed as a thing that requires
`roman-numerals` during the upgrade call but not during
`compile-requirements`. This just commits the expectations from
compile-requirements for now so we can land the package update.
Re-compilation and upgrade-package should be able to run without
updating the common_constraints.txt file. We do this all the time when
backporting fixes to older releases. We shouldn't pull in the latest
common_constraints.txt in those cases as they may not be compatible with
older releases.
BREAKING CHANGE: All references to the hardcoded 'proctortrack' string have
been removed from the codebase, as well as the `studio.show_review_rules`
waffle flag. These were used to determine whether an escalation email is
required and whether review rules should be shown. These decisions are now made
based on the value of 'requires_escalation_email' (default False) and 'show_review_rules'
(default True) config items in the PROCTORING_BACKENDS entry.
Additionally:
* The proctoring info api will now return the list of providers which require an escalation
email so that frontend-app-learning does not need to use a hardcoded check agaist
the provider name 'proctortrack'.
* Removed translation commands, mock variables and user facing strings that contained
'proctortrack'.
* Updated all test cases that were using proctortrack to use fake providers names.
Part of: https://github.com/openedx/edx-platform/issues/36329
Previously we would upgrade pip before we upgrade pip-tools. This
breaks when the latest version of pip is not compatible with the current
version of pip-tools as happened with https://github.com/jazzband/pip-tools/issues/2252
If we re-order the steps so that we upgrade pip-tools first, we know
that this upgrade call will work since it will run with the versions of
pip and pip-compile that ran the last full upgrade.
However in this case the pip.txt file is redundant as the pip-tools.txt
file already has the latest version of pip that is compatible with the
current version of pip-tools being installed.
This changeset also updates the compile-requirements command to ignore
the common_constraints entry for pip so that we can verify the upstream
fix of pip-compile before we remove the entry from
common_constraints.txt upstream.
Test with unpinning both pip and pip-tools. The latest versions have
fixed the pathing issues with `make upgrade` and the dependency
resolution issues reported in https://github.com/openedx/edx-lint/issues/458
* build: Update places where Arbi-bom was getting tagged.
The arbi-bom team no longer exists and we need to make sure these still
land in a timely manner. So tag the maintainers to review and merge
these PRs
* build: Drop unnecessary common_constraint overrides.
These are no longer necessary now that
https://github.com/openedx/edx-lint/pull/500 has landed.
BREAKING CHANGE: Removes all remaining Paver commands including
`pavelib/prereqs.py:*` and `pavelib/assets.py:*`.
BREAKING CHANGE: Removes `./manage.py [lms|cms] compile_sass`, which
was just a wrapper around Paver commands.
BREAKING CHANGE: Removes paver.txt. Operators should install testing.txt
instead.
Part of: https://github.com/openedx/edx-platform/issues/34467
See requirements/edx-sandbox/README.rst for more info
BREAKING CHANGE: edx-sandbox/py38.txt will not longer
be updated. Please install from either edx-sandbox/base.txt or
edx-sandbox/releases/*.txt instead.
We reimplement `make translations` so that it does not depend on the
presence of the `.git` directory. This fixes the Tutor build error:
> [production 18/34] RUN make clean_translations:
git clean -fdX conf/locale
fatal: not a git repository (or any of the parent directories): .git
make: *** [Makefile:57: clean_translations] Error 128
Why is the .git directory missing during the Tutor translations build?
Because if it were present, it would tie the translations' layer cache
up with git state, which would lead to the Docker layer being rebuilt
any time there was any change to git state.
This pull request pulls translations via atlas for `studio-frontend` and refactor `load_sfe_i18n_messages` to load new translations into `conf/plugins-locale/studio-frontend` instead of relying on deprecated node.js package bundled translations.
Sometimes this make target doubles or even triples the comment. I think
this is due to a temporary failure in the wget call, which is then ignored
and an additional comment is added onto the top. If this happens multiple
times in a row, you get multiple additions.
Removing the `|| touch` should fix this, and surface any errors that are
happening.
* fix: include new assets.txt file in make upgrade
* test: update click version to resolve upgrade job failure
* chore: Updating Python Requirements (#32861)
To make edx-platform more consistent with other IDAs and to
help deprecate more of paver, we are adding the ability to
run `make migrate` in a local environment as a replacement
for `paver update_db`.
https://github.com/openedx/devstack/issues/1085
* Swagger was renamed to OpenAPI at some point so use the new name for
clarity.
* Prefix with `lms` to make it clear that these are the APIs from the
LMS and may not all be available in the CMS.
* This project was not being published anywhere.
* The previous commit that adds openapi generation capabilities to the
`docs/guides` replaces what this was doing.
In different environments echo seems to handle escape characters differently.
When generating the common constraints file, on some systems it outputs the
"\n" character as-is. This change switches echo to printf, which is supposed to
be more consistent.
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.)
There was a `requirements/pip.txt` with old versions, and a newer
`requirements/edx/pip.txt` managed via a `pip.in` file. The old one was
used in most places, but came out of sync with pip-tools.txt, which was
managed properly. Eventually this caused a `pip check` failure due to the
mismatch.
This should resolve at least part of https://github.com/edx/edx-arch-experiments/issues/267
This PR moves pip.in and pip-tools.in and their corresponding pin files
up to the `requirements/` dir, since they should be shared between the edx
and sandbox environments. This also has the effect of upgrading pip to
match the version in the file we've been uselessly upgrading.
Other improvements:
- Remove `-q` option from pip and pip-sync calls, as it was hiding some
debugging information that would have resolved this sooner.
- Depend on `pre-requirements` from `compile-requirements`, rather than
from `upgrade`. (The base target is the one that actually needs it.)
This also lets us remove the explicit `pip install pip-tools` line.
- Install the recompiled pip and pip-tools files right away, not after the
loop. When we upgrade pip-tools, we want to use the upgraded version,
not the previous version. This requires moving the pip-tools.txt
recompilation outside of the loop and into its own explicit line.
- Don't upgrade pip if we're not running `make upgrade` (respect the
compile options).
- Remove apparently-unneeded `--no-emit-trusted-host --no-emit-index-url`
options (we don't pass trusted-host or index-url options).
