You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by po...@apache.org on 2023/03/12 02:44:14 UTC
[airflow] branch v2-5-test created (now d4afb041f8)
This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a change to branch v2-5-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
at d4afb041f8 Installing non-editable airflow for constraint generation (#30050)
This branch includes the following new commits:
new d4afb041f8 Installing non-editable airflow for constraint generation (#30050)
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
[airflow] 01/01: Installing non-editable airflow for constraint generation (#30050)
Posted by po...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch v2-5-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
commit d4afb041f87c502db904a985b2e63f4dd89a4b59
Author: Jarek Potiuk <ja...@potiuk.com>
AuthorDate: Sun Mar 12 03:20:47 2023 +0100
Installing non-editable airflow for constraint generation (#30050)
When we are generating constraints including released version of
providers or "no providers" (which effectively means preinstalled
version of providers only), we should use non-editable installation
of airflow.
Normally in CI, we have editable version of airflow and we install
providers from sources, but this leads to skipping installation
of the preinstalled providers (it is connected to the fact that we
were earlier installing as editable and "sources only" and those
packages are marked as required, which confuses newer version of
pip. It prints that the preinstalled packages are installed, but
it does not specify the version - apparently thinking the editable
version of the install already contains them.
Since our behaviour is pretty non-standard, this is not really a
bug in pip, but it is a bug in our approach when we are adding
providers for constraint generation. Rather than using editable
installation when we add providers, we should use "regular"
installation. This seems to remove the confusion and the preinstalled
packages are also installed.
(cherry picked from commit 05242e95bbfbaf153e4ae971fc0d0a5314d5bdb8)
---
scripts/in_container/_in_container_utils.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/in_container/_in_container_utils.sh b/scripts/in_container/_in_container_utils.sh
index 3240b2c90d..e0e8594954 100644
--- a/scripts/in_container/_in_container_utils.sh
+++ b/scripts/in_container/_in_container_utils.sh
@@ -261,7 +261,7 @@ function install_local_airflow_with_eager_upgrade() {
# we add eager requirements to make sure to take into account limitations that will allow us to
# install all providers
# shellcheck disable=SC2086
- pip install -e ".${extras}" ${EAGER_UPGRADE_ADDITIONAL_REQUIREMENTS} \
+ pip install ".${extras}" ${EAGER_UPGRADE_ADDITIONAL_REQUIREMENTS} \
--upgrade --upgrade-strategy eager
}
@@ -290,7 +290,7 @@ function install_all_providers_from_pypi_with_eager_upgrade() {
# Installing it with Airflow makes sure that the version of package that matches current
# Airflow requirements will be used.
# shellcheck disable=SC2086
- pip install -e ".[${NO_PROVIDERS_EXTRAS}]" "${packages_to_install[@]}" ${EAGER_UPGRADE_ADDITIONAL_REQUIREMENTS} \
+ pip install ".[${NO_PROVIDERS_EXTRAS}]" "${packages_to_install[@]}" ${EAGER_UPGRADE_ADDITIONAL_REQUIREMENTS} \
--upgrade --upgrade-strategy eager
}