Open tribbloid opened 5 years ago
Hello @tribbloid , thanks for reaching out. That is an interesting question, and I also would like to be able to update both the script and notebook within other editors than Jupyter Notebook or Lab.
One question: have you contacted the authors of VSNotebooks, either from the fork you cite, or from the original repo? I think such an extension has to be coded in Javascript, and I have no experience in that language yet.
Many people have posted on his issue tracker so far but evidently he is busy with something else.
I'll try to understand his sourcecode and see if I can take over, I don't write Javascript either but fortunately Scala.js (one of my favourite language) has full interoperability with it.
@mwouts sorry he is already trying to fix it, this is the thread:
interested in this as well. The VS code previewer is fixed now. I can use it normally with Ubuntu 16.04 today.
What's the current state of this? The vscode extensions for jupyter notebooks is already pretty nice, especially the preview one.
We just would need to find a way to open non-ipynb files with the extension and pipe everything through jupytext on every load/save. I don't think this can be hard, I just don't have any experience with vscode extensions.
Is there any progress on integrating JupyText
with the official extension of VS Code?
Looks like this is an ongoing attempt to make it possible: https://github.com/notebookPowerTools/vscode-jupytext
Hi @DonJayamanne,
your vscode extension looks great! I just wanted you to be aware of this discussion on the jupytext side, and I'm sure @mwouts would support any tighter integration between jupytext and the extension if that's something that would help you.
I'm happy to kill that extension in favor of an official extension from jupytext itself. We could either start now, or wait and see how popular my current VSCode extension gets and learn from it's mistakes. I know there are a few issues with that implementing.
Hi @DonJayamanne , it's great to see you working on this! (BTW I was much impressed already by your PythonVSCode extension :+1: )
Well to start with I'll be happy to add a pointer to your extension in the documentation when you feel ready for that.
Also let us know if you need dedicated commands (from https://github.com/notebookPowerTools/vscode-jupytext/blob/main/src/conversion.ts it seems that you are using jupytext --to
rather than --sync
, is that correct?)
Last but not least, I am wondering if it would make sense to develop a TypeScript implementation of Jupytext, for at least the percents formats (this could also be useful in the context of JupyterLab, cf. https://github.com/mwouts/jupytext/issues/381). What is your opinion on this? (NB: I know too little TS at the moment, but I'd be glad to learn!)
t's great to see you working on this! (
Thanks,
s that you are using jupytext --to rather than --sync, is that correct?)
Didn't want to go with Sync, because I don't think users really want an ipynb file, i think they just want to use the notebook UI. But thats my assumption. I'm happy to look into the sync option. Right now what i do is create an ipynb & use a virtual file system, when the notebook is saved in the virtual file system, then i save the file in *.py. I.e. there's no real ipynb file on disc.
I could look into the sync option, I think I just might end up going down that path, as the virtual file system has its own issues (relative paths to images in markdowns might not work).
hat is your opinion on this? (NB: I know too little TS at the moment, but I'd be glad to learn!)
For non python files, my plan is most definitely to use typescript. & my assumption is users don't really care much about the metadata (or don't store much of that).
I am wondering if it would make sense to develop a TypeScript implementation of Jupytext
I figured, if someone wants to open Python files, then they'd already have Python installed. Hence if python is installed, why re-invent the wheel, thus ended up using Python for Python files.
However if Python isn't installed, then yes the plan is to go with TypeScript, however my concern there was, thats a lot of code, supporting myst, sphynx (metadata, etc), that's a lot, & ensuring the conversion from Python to IPYNB & back to Python should be accurate, else we could have unnecessary changes that show up in SCM. That challenge seems to make me want to just throw in the towel and always require pyhton when editing Python files.
ur extension in the documentation when you feel ready for that.
Thanks, I would like to treat this as an exploratory extension. lets see what users really want from such an extension & what are the issues with this implementation.
telemetry
I'm planning on adding some telemetry to see if users have any metadata & the like in the plain text files. This will give an idea of the amount of work required in writing the typescript version of the parser.
I'd actually want to have 3 options:
.py
file while having a synched Jupyter file (So the work can be shared).I think those options cover all.
Having a saving mode which strips the non code cells.
Please upvote this issue https://github.com/microsoft/vscode-jupyter/issues/4670
Just curious and following up: What's the status on discussion of a VSCode extension? I'm aware of @DonJayamanne's extension, but it seems to only be Insiders. As a VSCodium user it would be really great to have such an extension, but I assume that having a stable VSCode extension is a prerequisite.
This is extension is great, but unfortunately it hasn't been updated in a while.
I think jupytext is essential when you work with other people on the same notebook. Synching .ipynb via git is a nightmare, but .py are really easy to handle.
I hope that there'll be some official jupytext-support for VCode in the upcoming releases.
A variation of the idea is proposed in https://github.com/microsoft/vscode-jupyter/issues/9514. Probably more support for that issue might derive MS to add this to VS Code.
I would love to see this become a reality. It has keeping me from trying Jupytext because I work exclusively in VS Code. I do not see myself returning to Jupyter. I would be happy to help but I have no experience on VS Code development.
Fingers crossed :crossed_fingers: Cheers
I don't think users really want an ipynb file, i think they just want to use the notebook UI.
For users that want to save the output as well, having the .ipynb file as well seems like a good option, and they can just exclude it from version control and use the .py file for that, so they get the best of both. It's also helpful when the .ipynb file is the main format they share across different platforms to enable viewing and editing wherever generating a notebook from the .py file isn't supported. If you do choose to add this then I recommend making it configurable so users can choose to use --to
and keep only the .py file if they want, or use --sync
and keep both the .py and .ipynb files if they want.
VSCode 1.79 added the notebook.codeActionsOnSave
setting, but unfortunately, similar to editor.codeActionsOnSave
, this does not allow you to run arbitrary user tasks (such as a shell script calling jupytext). My understanding is that we'd still need an extension that exposes a jupytext vscode command that can then be triggered by notebook.codeActionsOnSave
.
Is there anything for onClose
event?
This feature aims to combine Jupytext with features from the following 2 extensions:
The extension will become effective immediately after opening any .lgt.py file, on initialisation it will create a companion & hidden .ipynb under the same directory(thus avoided breaking relative path references).
The plugin should attempt to synchronise 2 files on save or when ''Run cell' command is invoked.
In later case the extension should also submit the updated cell to the backend ipython server, update the output section of the ipynb file, and display/refresh the nbreviewer.
The above is just what I would perceived as the default behaviour, this allows any user to start writing a python file like a latex document, and compile into python notebook, as well as all document supported by nbconvert in real time, and without any installation or configurations