Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

custom labextension path? #1494

Closed
dfguerrerom opened this issue Oct 2, 2024 · 2 comments
Closed

custom labextension path? #1494

dfguerrerom opened this issue Oct 2, 2024 · 2 comments

Comments

@dfguerrerom
Copy link
Contributor

dfguerrerom commented Oct 2, 2024

I was navigating through the documentation and the code but I couldn't find an answer to the following.

My group has a system where we have a jupyter server running from where users can launch some voila applications, for each app, we set the kernel that the app has to use and it is then launched.
The problem surges when there's a tool that needs a new labextension which is not installed in the system library, causing the no version of module xxx is registered.

By running jupyter --path I know that the registered extensions are located at:

    /home/username/.local/share/jupyter
    /usr/local/share/jupyter
    /usr/share/jupyter

I know I can export JUPYTER_PATH= var to add the folder of the venv that I'm using, but it won't solve my issue because the server is already running, I cannot change that...

Is there a way to set this path in a different way? or is there a way to use the cdn ?

@trungleduc
Copy link
Member

It's not possible to set the lab extension paths dynamically.
What we can do is to relax this fullLabextensionsUrl to make it configurable. Then you can host your extension assets independently of voila and update them without touching voila server

@dfguerrerom
Copy link
Contributor Author

I need this feature, and I could start a PR.
I thought that fullLabextensionsUrl would be the only entry point used afterwards to handle the extensions but not, to get the metadata from the extensions there's another call to the filesystem

labextensions_path,
...
To propose a generic solution I was thinking on adapting or adding gcp method to work directly with the server instead of the filesystem, in which scenario I would have to add some directory listing methods to the server and adapt the logic.
What do you think about it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants