feature/SOF-8040: add the jupyterLab application - #154
Open
VsevolodX wants to merge 5 commits into
Open
Conversation
jupyterLab was never carried over when applications moved from application-flavors into standata. It survives on production only on rows that predate the migration; a fresh deploy seeds from standata and so cannot create a Jupyter workflow at all. ApplicationsProcessor calls app.build.toLowerCase(), so each version carries an explicit build, which the original asset omitted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adding the jupyterLab application makes it selectable in the designer but puts nothing in the workflow bank, so there is still no Jupyter entry to start from — on production that row was hand-made in the database. One subworkflow with a single execution unit on the notebook flavor, carrying the jupyter_notebook_endpoint monitor that publishes the endpoint property. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| - version: '3.0.3' | ||
| build: Default | ||
| - version: '3.0.3' | ||
| build: with-pre-installed-packages |
Member
There was a problem hiding this comment.
These versions do not exist
|
|
||
| jupyterlab==3.0.3 | ||
| notebook>=6.2.0 | ||
| exabyte-api-client>=2020.10.19 |
Member
There was a problem hiding this comment.
should be mat3ra-api-client
We should have different flavors - with and without mat3ra-made
| # Build 'Default' builds it per job under the scratch directory; 'with-pre-installed-packages' | ||
| # reuses the shared environment, where packages cannot be added while the notebook is running. | ||
|
|
||
| jupyterlab==3.0.3 |
Member
There was a problem hiding this comment.
This should be matched to the version
Member
There was a problem hiding this comment.
Let's add 4.3.0 and the latest 4.6.0
…avor [release] Review round 1: - versions are now 4.6.0 (default), 4.3.0, 3.0.3 and 3.0.3/with-pre-installed-packages - each version line gets its own minimal requirements template, selected via supportedApplicationVersions the way espresso's pw.x flavors already do; the default flavor is pure JupyterLab, nothing else - notebook_mat3ra (>=4.6) preinstalls the packages the api-examples notebooks use; exabyte-api-client is replaced by mat3ra-api-client Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
VsevolodX
changed the title
VsevolodX
changed the title
Review found two blockers. Only 4.6.0 carried isDefault on its build, so
findApplication({name, version}) threw for 4.3.0 and 3.0.3 — the espresso asset
documents this as per-version. And only the >=4.6 flavor was isDefault, leaving
the older lines with no default flavor at all: a new unit at 4.3.0 or 3.0.3 had
nothing to resolve.
The ranges are disjoint, so each version line now has exactly one default
flavor. Ranges tightened to ~4.6 / ~4.3 so the range and the template's pin
cannot drift apart, with the pins now matching (jupyterlab==4.6.* / 4.3.*), and
the notebook and urllib3 pins say why they are there. tests/js/jupyterLab.test.ts
covers both blockers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SOF-8040 — one of four PRs; see the others in
rupy,web-app,ave.jupyterLabwas never carried over when applications moved fromapplication-flavorsinto standata. It survives on production only because those rows predate the migration; the webapp seedsapplicationsfrom standata (ApplicationsCreateFromInitialData), so a fresh deploy cannot create a Jupyter workflow at all. The ticket calls this out directly.Ported from
stack/lib/application-flavors: the application, thejupyterexecutable, thenotebookflavor and the requirements template, registered inapplication_data.yml,executables/tree.yml,templates/templates.ymlandcategories.yml.One change was required rather than a straight port:
ApplicationsProcessordoesapp.build.toLowerCase(), so every version needs an explicitbuild— the original asset omitted it and would have crashed the build. Both3.0.3builds are kept so existing platform jobs referencing them still resolve.Verified:
npm test200 passing, including the template context-provider check which now covers the jupyterLab template. The generated entities are byte-equal to records that were hand-seeded into a dev DB and used to run a real jupyterLab job end to end. Not verified by seeding a live instance from this build.Known inconsistency inherited from the source, not fixed here:
defaultVersion: 4.3.0against a template pinningjupyterlab==3.0.3.🤖 Generated with Claude Code