Minor Documentation Fixes: TaskID for Example Custom Flow; Comment on Homepage; More documentation for components

[LennartPurucker]

Closes#1241

Moreover, we might want to add or rework the process for the examples if the IDs can change, maybe in relation to #1227.

Also Closes#1229

Also CLoses related to #1231if we think this documentation suffices for the use case.

[codecov-commenter]

Codecov Report

Patch coverage: 100.00% and project coverage change: -7.75⚠️

Comparison is base (bb3793d) 85.24% compared to head (da9f1b1) 77.49%.

Additional details and impacted files

@@ Coverage Diff @@## develop #1243 +/- ##
===========================================
- Coverage 85.24% 77.49% -7.75% 
===========================================
Files 38 38 Lines 5008 5008 ===========================================
- Hits 4269 3881 -388 - Misses 739 1127 +388 

Impacted Files	Coverage Δ
openml/utils.py	91.25% <100.00%> (ø)

... and 15 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[LennartPurucker]

Patch coverage has no change and project coverage change: -0.10⚠️

We could add tests that verify that our examples are not crashing.
I am thinking about very simple tests like:

deftest_run_custom_flow_example():
example_code=__import__("examples.30_extended.custom_flow_")

This would increase the code coverage and would allow us to see if our examples are actually working.
However, I am not sure if this is really good practice (but I also have no better idea right now).
I would be fine with it, but I feel like this depends on your preferences.

[LennartPurucker]

We might want to connect this to #1070 and resolve both at the same time.

[mfeurer]

I agree that this closes #1241 and #1229. I am not sure if it documents #1231 sufficiently.

RE testing the examples: the examples are executed by the workflows that build and deploy the documentation. Therefore, we automatically check them, but they do not contribute to the test coverage.

RE #1070 I don't think we can resolve this as we also look into tasks, and they cannot be addressed by names.

[mfeurer]

Happy to merge if/when unit tests pass.

[LennartPurucker]

@mfeurer the usual tests seem to pass. Does that suffice for you? IMO, I want to have the docs build working.

If I have the time this week, I will try to fix all failing tutorials (while building the docs) and include these fixes in the PR. I think this would be appropriate with the current idea of the PR.

[LennartPurucker]

@mfeurer I think this is ready for merging now. Or do you require any other changes?

[PGijsbers]

Examples are tested, I don't really see a point for calculating coverage metrics on the example code itself. As far as I am aware, this is also not something we do. The difference in code coverage is more likely to be because of changes to the test server state (and thus different error/code paths). If there are parts of the code only covered by examples and not unit tests, then the right way to correct that would be to add unit tests.