Use set instead of list for dags' tags

[Avihais12344]

Closes issue 41420.

Thank you for viewing this PR :)

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[shahar1]

Overall, I agree with the idea that set is more appropriate in this case, as tags should be unique. I'd be happy for more opinions whether it's worth making it as a breaking chage.

[uranusjr]

This should probably just use Collection. We don’t really expect users to add more tags to a DAG after it’s created.

[Avihais12344]

I don't think it's true. In cluster policies, we may want to add custome tags to DAGs (for orginization hierarcy for example).
And I don't think it would be correct to make it an immutable collection that we would need to create every time we want to change something.

If we would go with Collection, we would go with a different programing paradigram, and I am not sure everyone would like it, so I would keep the door open and let everyone chose what they want to.

[uranusjr]

Do we need to support this?

[Avihais12344]

Overall I want to check behaviour, if we change the behaviour, we should know about it.
For example, changing the implementation of the tags from set to list would break this change, and we would know about it.

That's why I think we should have this test, but let's keep the conversation here, as we talk about the same thing.

[jscheffl]

I like this cleanup! Especially as is is "non-breaking" for existing DAGs, so no effect on DAG authors but better data types. Just small proposals to pin the typing to strings

[jscheffl]

Some tests fail, otherwise OK for me. Small nit as comments

[uranusjr]

I do not like this, but feel free to merge this without me if others feel more strongly this i beneficial.

[Avihais12344]

@uranusjr why you don't like this?

[uranusjr]

I mostly outlined the reasons above, but to summarise, you want to keep this mutable so you can call add after a DAG is created, but by changing this from a list to set, you are also breaking everyone that’s already adding tags after a DAG is created. The two things you are trying to do (use set instead of list, and keep the attribute mutable) have directly conflicted reasoning. IMO it is simply not worthwhile to break everyone so you can more easily handle duplicated tags. You can just do that easily in your own code.

With that said, 3.0 is the exact time to break everyone, so I am still open for this to be merged if people feel fine about it. But I will not approve nor merge this change myself.

[jscheffl]

I mostly outlined the reasons above, but to summarise, you want to keep this mutable so you can call add after a DAG is created, but by changing this from a list to set, you are also breaking everyone that’s already adding tags after a DAG is created. The two things you are trying to do (use set instead of list, and keep the attribute mutable) have directly conflicted reasoning. IMO it is simply not worthwhile to break everyone so you can more easily handle duplicated tags. You can just do that easily in your own code.

With that said, 3.0 is the exact time to break everyone, so I am still open for this to be merged if people feel fine about it. But I will not approve nor merge this change myself.

Would it make you more happy if we keep the interface as a list (so: non breaking) but during setting/init it is temporarily converted to a set to ensure no duplicates are in the list?

[Avihais12344]

@uranusjr I am sorry to hear you don't like my change. I think the solution of @jscheffl is reasonable to handle your conflict, even though I think we should break the interface to a set. Due to the release of Airflow 3, it's a great time (that may not come back) to break interfaces.

But can you (@uranusjr) at least close your conversations? As it blockes the merge request (that was approved by other people).
Thank you for your understanding.