You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@mmcky proposed the solutino that the following was added:
:tags: ["remove-cell"]
which should hide both input and output. He said that That way they will execute as part of jupyter-cache but neither input or output will be included for the code-cell that they are contained in for the html. Sounds good enough to me!
```{code-cell} python
:tags: ["remove-cell"]
print("Unit test running")
assert True, "Failure in unit test"
```
Instead of at the bottom, maybe put it after the text and before something else just so we can see if it messes up spacing. For example change the text in that lecture to be
### Exercise 1
Create a draft of the alternative way to organize time and education -- that is, have two subplots (one for each education level) and four groups of points (one for each year).
```{code-cell} python
:tags: ["remove-cell"]
print("Unit test running")
assert True, "Failure in unit test"
```
Why do you think they chose to organize the information as they did rather than this way?
OK, after adding that, then you need to verify a few things
Leave the assert True as on and generate the HTML. Verify that no funny business happened (e.g. no text shows up, there isn't a weird cell, etc.) and the spacing also wasn't drastically changed
Leave the assert True as on and generate the jupyter notebooks. Check if the jupyter notebooks generated with the "Unit test running" and maybe all of that code in a cell.
If so, then make sure an issue is posted on the appropriate repo and link to it from this issue. We can launch the notebooks with that small quirk at the end of that notebook until the feature is implemented. People can just ignore the cell until then.
I can't remember if we have pdf support yet, but if we do then do the same thing. Hopeefully the cell doesn't show up, but if it does then we should ensure an issue is posted - and not worry about the bug in the pdf output because the stakes are low.
Now modify the code to assert False etc. and run things to compille that file locally. Ensure that the error isn't just silent.
Make the change to assert False and then commit to a PR. Make sure that the error isn't just silent. This is a "breaking" change and it should be very visible in the CI in one form or another. If it stops the procses of building the full netlify/etc. for the PR that is fine - we just need to make sure the errors aren't silent.
The text was updated successfully, but these errors were encountered:
thanks for testing this idea our @arnavs@aadsouza -- anything you need my input on? I will use this work in making an adjustment to sphinx-tomyst for julia conversion.
@mmcky proposed the solutino that the following was added:
which should hide both input and output. He said that That way they will execute as part of
jupyter-cache
but neither input or output will be included for the code-cell that they are contained in for the html. Sounds good enough to me!Now to verify that this works prior to applying it all over the julia code, we should add in a single unit test in one of the lectures. And we should do it in a very "low risk" place. I suggest going to https://github.com/QuantEcon/lecture-datascience.myst/blob/main/src/applications/visualization_rules.md and adding in something completely at the bottom of the lecture that does
Instead of at the bottom, maybe put it after the text and before something else just so we can see if it messes up spacing. For example change the text in that lecture to be
OK, after adding that, then you need to verify a few things
assert True
as on and generate the HTML. Verify that no funny business happened (e.g. no text shows up, there isn't a weird cell, etc.) and the spacing also wasn't drastically changedassert True
as on and generate the jupyter notebooks. Check if the jupyter notebooks generated with the "Unit test running" and maybe all of that code in a cell.assert False
etc. and run things to compille that file locally. Ensure that the error isn't just silent.assert False
and then commit to a PR. Make sure that the error isn't just silent. This is a "breaking" change and it should be very visible in the CI in one form or another. If it stops the procses of building the full netlify/etc. for the PR that is fine - we just need to make sure the errors aren't silent.The text was updated successfully, but these errors were encountered: