Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default start_date and schedule_interval to None #24842

Closed
2 tasks done
Tracked by #41641
BasPH opened this issue Jul 5, 2022 · 8 comments · Fixed by #41453
Closed
2 tasks done
Tracked by #41641

Default start_date and schedule_interval to None #24842

BasPH opened this issue Jul 5, 2022 · 8 comments · Fixed by #41453
Assignees
Labels
airflow3.0:breaking Candidates for Airflow 3.0 that contain breaking changes airflow3.0:candidate Potential candidates for Airflow 3.0 kind:feature Feature Requests
Milestone

Comments

@BasPH
Copy link
Contributor

BasPH commented Jul 5, 2022

Description

I suggest changing the bare-minimum code required for instantiating a DAG:

# Proposed

from airflow import DAG
from airflow.operators.bash import BashOperator

with DAG(dag_id="no_schedule_dag") as dag:
    BashOperator(task_id="foobar", bash_command="echo hello")

This is currently not possible because start_date is a required argument:
image

I regularly see people using externally triggered DAGs and you're currently forced to set a placeholder start_date because Airflow requires it:

# Current situation

import datetime

from airflow import DAG
from airflow.operators.bash import BashOperator

with DAG(dag_id="no_schedule_dag", start_date=datetime.datetime(2022, 1, 1), schedule_interval=None) as dag:
    BashOperator(task_id="foobar", bash_command="echo hello")

When people want to set a schedule_interval, they intentionally think of it, so defaulting to None feels like a better UX to me.

Use case/motivation

To improve the Airflow user experience, I suggest removing the start_date requirement on DAG:

DAG(dag_id="my_dag")

This DAG could be triggered externally.

Related issues

No response

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

Code of Conduct

@BasPH BasPH added the kind:feature Feature Requests label Jul 5, 2022
@ashb
Copy link
Member

ashb commented Jul 5, 2022

The "default" schedule_interval is currently daily. I'm all for this so long as we can do it without breaking back-compat.

@BasPH
Copy link
Contributor Author

BasPH commented Jul 5, 2022

Yea that won't be possible. The default daily schedule interval has been there since the very first commit, and always felt like undocumented magic to me, and goes against Python's "explicit is better than implicit".

@ashb
Copy link
Member

ashb commented Jul 5, 2022

Then it's unlikely we can do it before 3.0

@ashb
Copy link
Member

ashb commented Jul 5, 2022

I think we might be able to do this by changing the function default to NOT_SET (a special singleton object) and then changing the value at runtime after checking other parameters.

(Changing the code-level default is possible so long as the behaviour to the user remains the same)

@potiuk
Copy link
Member

potiuk commented Jul 7, 2022

Yep. This looks like a good way to do it. Technically this is I think Sentinel. I used similar approach in Breeze where I wanted to distinguish "defaut" value from "last used" one

@malthe
Copy link
Contributor

malthe commented Jul 8, 2022

@eladkal
Copy link
Contributor

eladkal commented Feb 17, 2024

See also discussion here https://lists.apache.org/thread/hyctljm0o1odn1bntp4fcgok0d0433ov.

As of Airflow 2.8 start_date is not required when schedule=None
#35199

I think this solves this issue to the best we can do without causing breaking changes.

@uranusjr uranusjr added airflow3.0:candidate Potential candidates for Airflow 3.0 airflow3.0:breaking Candidates for Airflow 3.0 that contain breaking changes and removed involves core breaking change labels Aug 15, 2024
@uranusjr
Copy link
Member

With #41321 we should be set to do this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
airflow3.0:breaking Candidates for Airflow 3.0 that contain breaking changes airflow3.0:candidate Potential candidates for Airflow 3.0 kind:feature Feature Requests
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants