Answering Constance (somewhat it went to another thread:) > I know we rely on the example dags for dev purposes, especially for UI development. As part of moving them out of core, can we update breeze to automatically load them from their new home?
Yes. Very good point. I strongly think we need to do it. And it's part of the issue :). I already - in my PR - made it so in `breeze` and local venv where `tests` are part of the system we have now two "example" bundles - the second one coming from the standard provider. That was one of the reasons my PR was not green initially - because also some of our tests in core assume that "standard" provider examples are present. I adjusted some of them to expect "simplest" dag - where it made no difference, but I also created an extra dag bundle to add the standard provider in case the test system is importable locally in tests - so far so good. But I think in order to make things **really** work for breeze installation (and in local venv) - we would have to make it so the example dags are: a) available in the provider packages b) airflow should discover them from there I can (quickly) make a hack for Breeze (that's the question of adding standard provider's "tests" to PYTHONPATH) - in this PR - so It will cover that one and we will be able to regenerate documentation with links to sources. But I think in this discussion (and follow up PR) is to answer the question of what users should see when they enable it in "installed" airflow. * should users see the standard provider package dags when they install airflow locally from packages and say "load_example_dags". if we think "yes", then we generally need to include example_dags in provider packages (they are excluded now) - and we can do it, no problem. Now - I think we should also decide what users should "see" in this case - my first reaction would be "standard" + "simplest" + "maybe a few others? (which ones) ?" J. On Wed, Apr 30, 2025 at 1:12 PM Kaxil Naik <kaxiln...@gmail.com> wrote: > just an idea: With "git bundles", maybe example DAGs from standard provider > can be dynamically imported? > > But from your options: (1) seems reasonable > > On Wed, 30 Apr 2025 at 15:07, Jarek Potiuk <ja...@potiuk.com> wrote: > > > Hello here. > > > > While fixing a bug in the doc generation to bring "source" link to > example > > dags https://github.com/apache/airflow/pull/49978 I realized that we > have > > not moved a number of python/bash etc. example dags to standard provider > - > > where they now belong. I do it as part of my PR - but as result the > number > > of "example_dags" shown in the UI when "load example dags" is true is > going > > to decrease (and also they are not necessarily the dags you would really > > want to see). > > > > I thought maybe about a follow up PR where we will do a few things: > > > > 1) allow to show example dags also from providers (or maybe just standard > > provider) > > 2) limit a number of dags shown in airflow when "load example dags" > config > > is set - for example by tags - to only see those that are really useful > (I > > found the bash/python/comlex and few others really useful for quick > > demo/testing - maybe there are others). > > 3) We could optionally have "show all examples" setting for the "really > > power user case" and make it easy to test things in airfow UI > > out-of-the-box - or even limit it per provider. > > > > WDYT ? > > > > J > > >
