Skip to content

Improve myst workflow #440

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
twiecki opened this issue Oct 11, 2022 · 3 comments
Closed

Improve myst workflow #440

twiecki opened this issue Oct 11, 2022 · 3 comments

Comments

@twiecki
Copy link
Member

twiecki commented Oct 11, 2022

Me and many other contributors have had to fight with pre-commit and keeping the myst-file in sync. Hoping there are ways we can improve the workflow to make it less confusing. One thing I by default do is to remove the myst file and have it be re-created by pre-commit. Perhaps we could automatically have it be regenerated by pre-commit?

CC @OriolAbril

@OriolAbril
Copy link
Member

I have no idea about possible solutions, but streamlining all this would be very nice. I think one of the issues is I don't understand how pre-commit works when it's not doing run --all. I do understand jupytext though so I often use --no-verify because I am positive the two formats are perfectly aligned but I can't commit if I run pre-commit. And the pre-commit checks on github do pass when I do that.

@twiecki
Copy link
Member Author

twiecki commented Dec 24, 2022

At this point I would argue we should remove the myst_nb files and jupytext, it's not worth the hassle and I don't see a reason for us to carry around two formats where one works, especially now that github has better jupyter NB diffs.

I don't think jupytext fits into our workflow. For example, we run all these re-formatters on the NB files which always brings them out of sync, so conflicts are almost guaranteed. And I don't think we should drop those. And jupytext does not seem to have any functionality built for this, or allow you to specify to defer to the ipynb version when in doubt. It's also not trivial to just nuke and recreate everything.

So ultimately it's a little bonus for a few people (not me), but a huge hassle and confusion for everyone.

@twiecki
Copy link
Member Author

twiecki commented Dec 27, 2022

#483 is hopefully good enough, I'll close this in the assumption that it will be.

@twiecki twiecki closed this as completed Dec 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants