Upgrade embed to 3.15 #4661
Upgrade embed to 3.15 #4661
Conversation
|
This can only pass if someone in the jupyterlab org publishes the new npm package, I think.
|
|
@jasongrout Can you help me with this one? I'm happy to update and rebase when we have figured out how I can rename the package. |
|
Do you imagine that there will ever be parallel releases of a vega2 and vega3 extension? Are there ever any situations where someone will want to have both vega3 and vega4 installed? |
|
Possibly, but I would say that the jupyterlab package should always track the latest versions and we can publish vega2, vega3, vega4, vega5... packages in https://github.com/jupyterlab/jupyter-renderers/. |
|
Sure, that makes sense. Right now I'm spending cycles on the services package rework in #4697, but I can help with this after that. CC also @afshin or @ian-r-rose or @saulshanabrook, who might be able to help more quickly. |
|
The rename makes sense to me. What do you think @ellisonbg? I am a little surprised that the tests would be failing without having published the vega package, especially the js tests. Are they working for you locally? |
domoritz
force-pushed
the
dom/embed-pi
branch
2 times, most recently
from
6f44501
to
add3ac3
Compare
domoritz
force-pushed
the
dom/embed-pi
branch
4 times, most recently
from
e0762cc
to
39fabbd
Compare
|
After talking to @ian-r-rose, I decided that it's better not to remove the version from the package so we can allow multiple versions at the same time. |
| primaryFileType: 'vega3', | ||
| fileTypes: ['vega3', 'json'], | ||
| defaultFor: ['vega3'] | ||
| name: 'Vega', |
There was a problem hiding this comment.
I wonder if these should still be 'Vega 4' and 'Vega-Lite 2' , in order to not have a name clash if a user wants to install multiple versions on their distribution.
There was a problem hiding this comment.
I think if we track the latest version, it's cleaner to just show the library. I don't have strong opinions here, though.
There was a problem hiding this comment.
I suppose that's fair. If you feel this is ready, I can publish the current version.
There was a problem hiding this comment.
From my side, it's ready to go.
|
I'm not really sure how to get the tests working here. It seems like a mistake to have our CI depend on whether the packages in a given PR have been published, or whether they have changed names. Any ideas @afshin or @jasongrout? |
|
Not sure if this is related, but it is real and painful for lerna-based
extensions/customizations... the whole thing/thing-extension pattern is not
achievable without direct hacking of the staging/node_modules.
I really dislike having to run a verdaccio instance to get around it, but
it does work... Though I never got the local auth to work well enough to
use in ci.
|
|
@bollwyvl Could you extrapolate what you mean by "the whole thing/thing-extension pattern is not |
|
As of 0.32, one cannot follow the pattern in core of an unpublished,
non-extension package being used by an extension, both being developed at
the same time. An example would be a syntax highlighter, which isn't
lab-specific, which you'd like a labextension to be able to install.
I think this was fixed with #4543 , though, so should be better in 0.33...
I try not to build extensions against master.
Verdaccio is a local caching proxy npm registry...
https://github.com/verdaccio/verdaccio
You still need registry.npmjs.org to use it, but it does allow a developer
to "publish" packages to overcome the dreaded "not available in network"
error during local development.
However, it can't really solve the "needs access to Internet at extension
install time" problem. I look forward to revisiting #2065 with a newer yarn
once 0.33 drops, as to my knowledge yarn's offline-mirror capability is the
most feasible solution given our current build. SystemJS might work, and
even get rid of the end user nodejs, but the per-file request overhead is
brutal.
|
|
I opened #4809 to track the underlying problem of not being able to get CI to pass on unpublished packages, so we can address that at a later date. |
lock
bot
added
the
status:resolved-locked
I also rename vega3 to just vega4.
Corresponding PR to add vega3 extension: jupyterlab/jupyter-renderers#139