IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This looks pretty hairy, but essentially it's just re-invoking `pip download` with `--no-deps` so that I can record the name of the local archives that are created.
I had to pull the git urls out of the main requirements files because in order to install offline (--no-index), we need pip to install from local package archives rather than cloning repo.
The weird `cat` thing going on in the Makefile is because we need to install everything as part of a single `pip install` transaction. Without this, installing only requirements_git.txt will result in dependencies getting unintentionally updated.
For some reason -I wasn't cutting it. Even though we were trying to install pip 8.1.2, this was happening:
Collecting pip==8.1.2
Using cached pip-8.1.2-py2.py3-none-any.whl
Installing collected packages: pip
Successfully installed pip-9.0.1
¯\_(ツ)_/¯
- Renamed npm scripts to reflect what they are actually doing. Nothing is being built here!
- Not sure why the default django_host was 0.0.0.0…
- Removed unnecessary logic from build-docker-cid
A couple reasons for this:
- The command for generating the API l10n files is currently broken, and I want to get the translation folks looking at the UI ASAP.
- These things require different environments:
- Generating the UI files requires Grunt, which is only available *before* packaging. We generate the static files before invoking mock or pbuilder.
- Generating the API files requires Django, which is only available inside the virtual environment. This will likely need to be invoked somewhere inside of the install playbooks.
https://patchwork.kernel.org/patch/8784071/
While renaming the policy would have been a “cleaner” solution, this would create a scenario where our setup playbooks would need to check for the policy by it’s old name before installing the new one. Updating the filename to reflect the policy name is the least invasive and risky change.
