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
This is somewhat related to #1816, and the use case is basically the same: easy batch handling of md/ipynb conversion where users don't modify their source files.
Having a custom myst.yml file will make it easier to build tools (possibly thin wrappers for myst) that produce templated myst.yml files in known, possibly temporary locations and can deliver the generated output to the user.
In our case at Berkeley (described in #1816) we could for example wrap that into small server-side tools triggered by a user menu or button in JupyterLab.
Proposal
The CLI should allow for a custom path to the myst.yml file. I suggest --config= for the option name (with -c as short option).
My take is that if this which if given, would override the search and only work if the given location is valid. This will allow also for overriding the local yaml file when desired, without disturbing the project (useful in cases where one is experimenting with more than one yaml file for various output scenarios).
This is somewhat related to #1816, and the use case is basically the same: easy batch handling of md/ipynb conversion where users don't modify their source files.
Having a custom
myst.yml
file will make it easier to build tools (possibly thin wrappers for myst) that produce templatedmyst.yml
files in known, possibly temporary locations and can deliver the generated output to the user.In our case at Berkeley (described in #1816) we could for example wrap that into small server-side tools triggered by a user menu or button in JupyterLab.
Proposal
The CLI should allow for a custom path to the myst.yml file. I suggest
--config=
for the option name (with-c
as short option).My take is that if this which if given, would override the search and only work if the given location is valid. This will allow also for overriding the local yaml file when desired, without disturbing the project (useful in cases where one is experimenting with more than one yaml file for various output scenarios).
Additional notes
Original discussion on discord.
The text was updated successfully, but these errors were encountered: