Fix empty file creation

[davidbrochart]

Description

See #425, #352.

Checklist

• PR has a descriptive title and content.
• PR description contains references to any issues the PR resolves, e.g. Resolves #XXX.
• PR has one of the labels: documentation, bug, enhancement, feature, maintenance
• Checks are passing.
  Failing lint checks can be resolved with:
  • pre-commit run --all-files
  • jlpm run lint

---

📚 Documentation preview: https://jupytergis--426.org.readthedocs.build/en/426/
💡 JupyterLite preview: https://jupytergis--426.org.readthedocs.build/en/426/lite

[github-actions]

👈 Launch a Binder on branch davidbrochart/jupytergis/empty-file

[davidbrochart]

This is not the final solution, but I don't think what we had could work in the general case.

[martinRenou]

Thanks @davidbrochart ! Would it make sense to move this logic in the front-end?

[github-actions]

Integration tests report: appsharing.space

[brichet]

@davidbrochart Why do we need to remove this ?
Do we have another way to create the file from the API ?

[davidbrochart]

I think this deserves more discussion, but my take is that the kernel's file system is in the general case unrelated to the JupyterLab file system. I know that in JupyterLite we can mount the frontend file system in the backend filesystem, but this is usually not the case in JupyterLab. Therefore I think that the kernel should always use a special API (the "Jupyter filesystem API") to access files. This API could be a Jupyter widget, and the data might travel from the kernel to the frontend, and back to the backend, which may look unnecessary at first point, but in the general case the "kernel backend" is not the same as the "server backend".

[martinRenou]

On a short term, can we solve this by only making file-system calls from the front-end? So this file creation logic could be moved in our Lumino plugin?

[davidbrochart]

Sure, but an even faster workaround is to just remove that logic, which I think is not present in JupyterCAD?

[brichet]

Sure, but an even faster workaround is to just remove that logic, which I think is not present in JupyterCAD?

It may be confusing for user to provide a path, have a widget with no error but cannot retrieve the file later, no ?
We should at least raise an error if the path does not exists I think.

[martinRenou]

Yeah unfortunately removing this without a replacement is not an option IMO. Users get confused the file is not created.

We should find a good solution and port it to JupyterCAD.

[davidbrochart]

I think that a Jupyter widget implementing a filesystem API should not be very complicated, and benefit both JupyterGIS and JupyterCAD (and even beyond).

[martinRenou]

Although I fully agree with your Jupyter filesystem API idea and how it would solve our issues here, having it a jupyter widget going through the front-end is not ideal IMO. I'd love a solution that don't require a browser front-end.

[davidbrochart]

Well the Jupyter widgets protocol (and Comm in general) doesn't require a browser per say, right?

[martinRenou]

Good point 👍🏽

[martinRenou]

Since we already have a widget here, creating the file ourselves from there, in the front-end, may be the easiest for now.

[martinRenou]

Closing, I'll include it as part of #412