Request for best practices/guidance on creating stable extensions which aren't version-dependent #13971
Comments
jupyterlab-probot
bot
added
the
status:Needs Triage
|
Thanks @rickmcgeer This is really unfortunate and the goal was to still be backward compatible even with the RTC changes. In the case of the failure with 3.6.1, would you be able to share some error traces? I think the way to restore backward compatible is to restore |
|
For reference to compare the changes: 3.5.x...v3.6.1 |
|
@fcollonval thanks for the kind words. Here's the trace. This was under JupyterLab 3.6.1 Dependencies from package.json: |
|
But this was less a request for backwards compatibiltiy of shared models (I understand this is under rapid development) than a genuine request for guidance; developers like me should wait for a stable release of shared editing. It's mostly that I can't find another way to open, read, and write a file using the JupyterLab API, which I think is likely ignorance on our part, not a development problem. |
|
cc @sebreb who may have found a similar issue when updating from 3.5 to 3.6 (feel free to open a separate one otherwise, thanks!) |
|
Thanks for the error trace @rickmcgeer Primary comments,
The main API break I'm seeing is: We introduced a new And unfortunately it seems you defined your own |
|
@fcollonval here is the yarn.lock file. I appreciate that this is a lot to go through, so in an hour I'll write an awk script to pull out the relevant versions, but I wanted to have the ground truth on the record before I reduce it. |
|
@fcollonval here are the versions from the yarn.lock file, reduced. I am not sure if the dependency lines represent separate versions or not. |
|
@fcollonval And here is the logfile from the prebuilt extension. I'm happy to provide code, commentary, anything at all toe get this resolved. And many thanks. |
That is quite possible, and, as I said, I believe the real fix for this is for me to fix our code. We are really asking for best-practices guidance here. What typically happens here is that our code breaks due to some change in the underlying API, and we do the best patch we can think of to make it consistent with the underlying API. Unfortunately, I don't really understand the underlying API all that well (I mostly just guess by looking at the existing code; I've been unable to find an extension example with functionality close to ours) and so it's entirely possible I'm making lots of mistakes. What we want to do is really simple...it really would be a few lines of Python (or whatever) over a POSIX filesystem API. We just want to (a) read files; (b) write files; and (c) install an icon on the launcher and a few menu items on the File dropdown and file browser context menus, which trigger file actions. So I'm sure there's a really short and simple way to do this, but I haven't been able to find it. |
|
Well, I am slowly going mad. I tried to fix this by having Here's the output of yarn listr @jupyterlab/docregistry: So it looks like a version problem, but what I don't get is Thanks |
|
And in fact (further digging) in |
|
Thanks for all the information, I opened engageLively/jupyterlab-universal-extension#1 to be able to comment directly on your code to help you improve it. |
JasonWeill
added
documentation
and removed
status:Needs Triage
|
Leaving this open as a documentation enhancement — we have an API, and we have extension documentation, but we don't have our own best practices document yet. |
|
To add here: we do not have a separated stable API subset for extensions; we could consider freezing a subset of API which is critical for most extensions. This could be also helpful for security hardening (by only exposing a subset of our API in a hypothetical future hardened mode) |
|
@fcollonval, I have invited you to the repo (reader, if you need more
privileges let me know and I will add them).
When you accept I will ask you to review the PR, and thanks again.
…On Fri, Feb 17, 2023 at 1:20 AM Frédéric Collonval ***@***.***> wrote:
Thanks for all the information, I opened
engageLively/jupyterlab-universal-extension#1
<engageLively/jupyterlab-universal-extension#1>
to be able to comment directly on your code to help you improve it.
—
Reply to this email directly, view it on GitHub
<#13971 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFAHAYMGF3PBZKHF7EWLXLWX47GBANCNFSM6AAAAAAUZ3SNBM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Rick McGeer
***@***.***
+15103346004
|
|
Our hope is that this extension will make many other extensions
unnecessary (or, more precisely, will permit other extensions to be
implemented simply by changing the config files of this one). This
extension opens an external editor in an iframe and manages load/store into
the filesystem and communication from kernels to the external editor. ATM,
the URL of the external editor, the commands, menu items, and messages are
hardcoded, but they could be in configuration files; so once this is put on
a sustainable path we hope to work with the community to generalize it to
make extensions easier for people to do.
…On Thu, Feb 23, 2023 at 10:14 AM Jason Weill ***@***.***> wrote:
Leaving this open as a documentation enhancement — we have an API, and we
have extension documentation, but we don't have our own best practices
document yet.
—
Reply to this email directly, view it on GitHub
<#13971 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFAHA4XHXNFBY5B4JNFEJLWY6SHPANCNFSM6AAAAAAUZ3SNBM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Rick McGeer
***@***.***
+15103346004
|
Problem
CodeEditor.Model, DocumentRegistry.ICodeModel) changes. For example, the current version works very well with JupyterLab 3.5, but fails with 3.6.1 -- we believe because theYFileclass has moved.Obviously, we'd prefer to implement an extension that isn't version-dependent. Some version dependency will always be there, of course, but ATM we're tweaking with each minor-version release.
Proposed Solution
Our internal diagnosis is that we're likely extending the wrong classes to implement our solution. However, we've been unable to find in the documentation, or the extension examples, preferred methods of reading and writing files, or the contract that a
CodeEditor.Modelsubclass should support.We (and we suspect, others who write editor extensions) would really appreciate guidance on this, ideally with a very simple example extension. We're prepared to contribute our extension, or a simplified version of it, to the extension-examples repo to help people out with this. But, first, we need to make it robust, and we'd appreciate guidance on how to do that.
Additional context
The text was updated successfully, but these errors were encountered: