o-nikolas commented on code in PR #47281:
URL: https://github.com/apache/airflow/pull/47281#discussion_r1978113052
##########
contributing-docs/07_local_virtualenv.rst:
##########
@@ -154,6 +154,24 @@ dependencies - including their runtime dependencies.
This will synchronize all extras of airflow (this might require some system
dependencies to be installed).
+Syncing provider dependencies only
+...................................
+
+Sometimes you want to only work on a specific provider and you only want to
install that provider
+dependencies and run only that provider tests. This can be done very easily
with ``uv`` by going to
+the provider's folder and running ``uv sync`` there. For example, to install
dependencies of the
+``mongo`` provider, you can run:
+
+.. code:: bash
+
+ cd providers/mongo
+ uv sync
+
+Then running tests for the provider is as simple as running:
+
+.. code:: bash
+
+ uv run pytest
Review Comment:
This is awesome! Can we provide arguments to the pytest command as you would
normally? E.g.: `uv run pytest tests/unit/some/specific/test/module/path -k
"some_specific_test_name"`
##########
contributing-docs/07_local_virtualenv.rst:
##########
@@ -154,6 +154,24 @@ dependencies - including their runtime dependencies.
This will synchronize all extras of airflow (this might require some system
dependencies to be installed).
+Syncing provider dependencies only
+...................................
+
+Sometimes you want to only work on a specific provider and you only want to
install that provider
+dependencies and run only that provider tests. This can be done very easily
with ``uv`` by going to
+the provider's folder and running ``uv sync`` there. For example, to install
dependencies of the
Review Comment:
```suggestion
Sometimes you want to only work on a specific provider and you only want to
install that provider's
dependencies and run only that provider's tests. This can be done very
easily with ``uv`` by going to
the provider's folder and running ``uv sync`` there. For example, to install
dependencies of the
```
##########
contributing-docs/testing/unit_tests.rst:
##########
@@ -1095,12 +1095,12 @@ are not part of the public API. We deal with it in one
of the following ways:
1) If the whole provider is supposed to only work for later airflow version,
we remove the whole provider
by excluding it from compatibility test configuration (see below)
-2) Some compatibility shims are defined in
``tests_common.test_utils/compat.py`` - and they can be used to make the
- tests compatible - for example importing ``ParseImportError`` after the
exception has been renamed from
- ``ImportError`` and it would fail in Airflow 2.9, but we have a fallback
import in ``compat.py`` that
- falls back to old import automatically, so all tests testing / expecting
``ParseImportError`` should import
- it from the ``tests.tests_utils.compat`` module. There are few other
compatibility shims defined there and
- you can add more if needed in a similar way.
+2) Some compatibility shims are defined in
``tests-ccommon/src/tests_common/test_utils/compat.py`` - and
+ they can be used to make thetests compatible - for example importing
``ParseImportError`` after the
Review Comment:
```suggestion
they can be used to make the tests compatible - for example importing
``ParseImportError`` after the
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
