Consider archiving this repository

[chrisjsewell]

Similar to executablebooks/rst2myst#5,
I would consider archiving this repository, in favour of https://github.com/executablebooks/rst-to-myst

although I note this one has been updated more recently, so won't do it without discussion

cc @choldgraf @AakashGfude @mmcky @jstac for comment

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[choldgraf]

I don't understand the comparative differences between this and rst-to-myst, so I'll defer to others there. But in general, if they have heavily overlapping functionality, I am +1 on deprecating one of them. One possibility is that if this repository is still needed by the QuantEcon team, we could just move it to the QE org?

[mmcky]

@chrisjsewell my plan is to move this to QuantEcon org once we are finished migrating all our major projects.

• https://python-programming.quantecon.org/intro.html
• https://python.quantecon.org/intro.html
• https://python-advanced.quantecon.org/intro.html (Due: Monday, 28th June)
• https://datascience.quantecon.org/intro.html (Due: Monday, 28th June)
• https://julia.quantecon.org/intro.html (Due: July)

sphinx-tomyst has been a very useful migration tool.

@choldgraf this extension basically allowed you to add sphinx_tomyst as a sphinx extension and run make myst to generate a myst version of a sphinx project. But I haven't used rst-to-myst much to see how it migrates projects. I think direct translation of rst-to-myst is technically superior approach so happy to move sphinx-tomyst to the QuantEcon organisation. The downside of sphinx-tomyst is it mainly works for core rst (i.e. docutils + sphinx) as it infers from sphinx.ast

I was thinking of writing a migration guide for sphinx rst projects so I will certainly give rst-to-myst a spin. @chrisjsewell does this work well for migrating projects in bulk? Last time I gave it a spin it translated single files.

[chrisjsewell]

Yeh once executablebooks/rst-to-myst#18 is merged (hopefully tonight) it will essentially be a lossless conversion and also output nice formatted Markdown with https://github.com/executablebooks/mdformat-myst.
This is something you just cannot do with the "standard" docutils AST, which this package works on, because there is literally no way to know for sure what the original text was e.g. what the original roles/directives used were.
Obviously its great that it worked for you but yeh, advertising it as a general tool, you would very rapidly rack up people opening bug issues

does this work well for migrating projects in bulk? Last time I gave it a spin it translated single files.

still single file at present, but its pretty easy to add in-place conversions + file globbing, and so have a command that walks through and converts every file in a project, i.e. there is no requirement for any extra "inter-document" logic, you just point it at whatever text you want and it will convert it.
I'll probably also do this tonight/today as well.

[mmcky]

@chrisjsewell i agree. I'm happy not to maintain this as soon as rst-to-myst is good to go. Happy to also debug and test any bulk conversion / project conversion feature. Thanks @chrisjsewell