There's nothing we can add in to the provider for this case -- as if
the user tries `@task.docker` on Airflow 2.1 no code in the provider is
ever run.
-a
On Thu, Sep 30 2021 at 12:03:34 +0200, Jarek Potiuk <[email protected]>
wrote:
On Thu, Sep 30, 2021 at 10:46 AM Ash Berlin-Taylor <[email protected]
<mailto:[email protected]>> wrote:
The new docker provider will still install and work on Airflow 2.1
-- the only change is to add a new field to the provider info dict
(`task-decorators`) that Airflow 2.2 will read, but that Airflow 2.1
will use.
If you try to use `@task.docker` in Airflow it will fail with
"_TaskDecorator has no property docker" which I think is fair -- and
the docs about this feature say
(<http://apache-airflow-docs.s3-website.eu-central-1.amazonaws.com/docs/apache-airflow/latest/tutorial_taskflow_api.html#using-the-taskflow-api-with-docker-or-virtual-environments>):
Right - if using the task.docker in Airflow 2.1 is not a silent
ignore but a failure, then I agree - we should not bump the minimum
version.
I guess however that we could give a clearer error message?
We've had too many of those cases where our error messages did not
really tell the user what is the reason - resulting in the users
opening issues and asking "I have no idea what this is about" (which
I believe will happen in this case).
Is it possible to add it quickly before we release the provider?
Something like ("Note That this decorator only works for Airflow 2.2+
- if you use an earlier version please migrate to 2.2 or above)"
J.
