Different behaviour when running Quarto with a Python wrapper vs direct CLI command

[imdando]

Description

Possibly not really a Quarto problem, but thought it'd be worth writing up anyway at the very least for some visibility. 

Repro environment and steps:

Quarto version: 1.5.57 (installed using pip install quarto-cli)
Python version: 3.12.5

pip install quarto-cli
pip install pandas
pip install matplotlib

Sample repro.qmd

---
title: "repro"
format: 
  html:
    embed-resources: true
    echo: false
jupyter: python3
keep-md: true
---

```{python}
#| echo: false

import pandas as pd

df = pd.DataFrame({
    'A': [1, 2, 3],
    'B': [4, 5, 6]
})
df.plot.barh()
```

This QMD works fine when rendering it via the cli i.e. quarto render repro.qmd.
However, when using a python wrapper script to call the cli, the figure isn't displayed, but instead just displays the text "<Axes: >"

import subprocess

quarto_cmd = ["quarto", "render", "repro.qmd"]
subprocess.run(quarto_cmd, check=True)

The different behaviour when running it directly via the CLI vs invoking from a python really stumped me for a bit, but it seems to be problem with the jupyter output being incorrect when quarto is invoked as a python subprocess, as it outputs this intermediate md

::: {.cell-output .cell-output-display execution_count=1}
```
<Axes: >
```
:::
:::

I finally figured a way to get it to display correctly with some help from a colleague.
Had to explicitly display the figure using the qmd below, but wondering if anyone may have more colour about what could be causing this difference in behaviour?
Perhaps the Python kernel being spawned for Jupyter execution when Quarto is running as a python subprocess is different?

```{python}
#| echo: false

import pandas as pd
from IPython.core.display_functions import display

df = pd.DataFrame({
    'A': [1, 2, 3],
    'B': [4, 5, 6]
})
display(df.plot.barh().figure)
```

[imdando]

Closed as my colleague raised this issue instead so that it has more visibility.
#10752

[mcanouil]

There is no such thing as "more visibility". The team is watching all issues and discussions.
This only means more work as the team will go through the two.

Not getting an answer over the weekend is not sufficient reason to duplicate reports.

PS: this comment is especially true if your colleague was aware of your discussion which was the case based on the reference.

[imdando]

Thanks for the response @mcanouil.

There were just some differences in opinion as to whether this would be more suitable as a discussion/question or an actual bug/issue that needs resolving. Apologies if this sent the wrong message.

I've closed this now to try to avoid the duplication.

[mcanouil]

Discussion is fine to start working on something. If it's a bug, we can open an issue from this discussion.
No apologies needed. It was simply to explain that we do the triaging and that it does not really matter if you open an issue or a discussion, as long as it's not both within the same time frame.

Still, thank you for the report.
We'll get back to the issue when we had time to look into it.