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

Enable dynamic?federated extensions in dev mode #9235

Closed
echarles opened this issue Oct 28, 2020 · 2 comments · Fixed by #9286
Closed

Enable dynamic?federated extensions in dev mode #9235

echarles opened this issue Oct 28, 2020 · 2 comments · Fixed by #9286
Labels
enhancement status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone

Comments

@echarles
Copy link
Contributor

echarles commented Oct 28, 2020

Problem

For now, the dynamic?federated extensions are forced-disabled in dev_mode

self.labextensions_path = []
self.extra_labextensions_path = []

Sometimes, like the work done in #8804, we need those extensions enabled in dev mode

Proposed Solution

Add a setting/flag like --extensions-dev-mode to keep the extensions enable in dev mode,.

@jtpio
Copy link
Member

jtpio commented Oct 28, 2020

Maybe this could even replace the add:sibling script, if third-party federated extensions can be installed in dev mode.

@jasongrout
Copy link
Contributor

We discussed this in a meeting, and realized that it's more subtle, since you'd want to use yarn link to install the dev core packages into the federated extension. Essentially, since the core extensions are all in a monorepo, yarn automatically links them all together so they see the version that is on disk, but since a federated extension would be in a different repo, we'd need to do that linking ourself.

That said, we could have a federated extension compiled against a released set of core packages, but then loaded in dev-mode with the dev packages. For many situations, this would work (even if it complains if the dev mode versions do not match the existing released versions).

jasongrout added a commit to jasongrout/jupyterlab that referenced this issue Nov 5, 2020
This is a much easier way to develop extensions against a development install of JupyterLab than the current add:sibling approach. While it may not work all the time, I think it will be helpful sufficiently often that we should make it possible.

Fixes jupyterlab#9235
@jasongrout jasongrout added this to the 3.0 milestone Nov 5, 2020
@github-actions github-actions bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label May 6, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 6, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants