[Core feature] Revisit enabling FlyteDeck by default for Python tasks.

[thomasjpfan]

Motivation: Why do you think this is important?

With flyteorg/flytekit#2248 and flyteorg/flytekit#2264, FlyteDecks will show the source code and python dependencies for Python tasks. This makes FlyteDecks universally useful for Python tasks.

Goal: What should the final outcome look like, ideally?

At least for Python tasks, it'll be great if enable_deck is True is the default.

Describe alternatives you've considered

The alternative is to keep the current default. Historically, FlyteDecks were turned off because there was a large overhead for rending large dataframes in the Inputs or Outputs.

We can mitigate this issue by trimming the source code being rendered and not show the inputs or outputs by default. I do not think there is a large use case for partially rendering inputs and outputs in the FlyteDeck.

An extension to this proposal is to add a new default_decks parameter to task:

@task(decks=["source_code", "dependencies"])

If a user wants to include the "input" deck, then can write: decks=["source_code", "dependencies", "input"]

Are you sure this issue hasn't been raised already?

• Yes

Have you read the Code of Conduct?

• Yes

[dosubot]

The proposal to enable FlyteDeck by default for Python tasks in Flytekit is an interesting one. As you've mentioned, the changes made in flytekit/pull/2248 and flytekit/pull/2264 allow FlyteDecks to show the source code and python dependencies for Python tasks. This could indeed enhance the user experience by providing more visibility into the tasks' data.

However, as you've pointed out, there are potential performance implications to consider. The generation of HTML reports for task inputs and outputs could introduce overhead, especially for tasks with large or complex outputs. This is something that needs to be carefully evaluated.

The alternative solution of keeping the current default due to the historical reason of FlyteDecks being turned off because of the large overhead for rendering large dataframes in the Inputs or Outputs is also a valid point. The proposed mitigation for this issue to trim the source code being rendered and not show the inputs or outputs by default could be a good compromise.

The suggestion to add a new default_decks parameter to task is a good one. This would give users more control over what they want to include in the decks. The example you provided:

@task(decks=["source_code", "dependencies"])

is a good illustration of how this could work. If a user wants to include the "input" deck, then they can write: decks=["source_code", "dependencies", "input"].

In conclusion, the proposal to enable FlyteDeck by default for Python tasks in Flytekit, with the addition of a new default_decks parameter to task, could be a good way forward. However, the potential performance implications need to be carefully evaluated and mitigated. It would be beneficial to gather more feedback from the community on this proposal.

Sources

• docs/flyte_fundamentals/visualizing_task_input_and_output.md
• docs/user_guide/development_lifecycle/decks.md

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[pingsutw]

+1 to enable it by default

[novahow]

#take