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
Update jupyterlite
dependencies and docs
#1001
Conversation
Pending jupyterlite/pyodide-kernel#23 and a release of |
Since we're requiring Python 3.8+ in Or just test on 3.8 instead of 3.7. |
OK I think this should be good to go now. Planning to make a new 0.1.0b19 release of both Some follow-ups items for later:
|
actions=[U.do(*args, cwd=cwd)], | ||
file_dep=file_dep, | ||
name="py:jupyterlite", | ||
actions=[U.do(*metapackage_args, cwd=P.ROOT)], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removing any existing file_dep
is a recipe for having to re-run stuff over and over again with no reason, and probalby out of order. ideally, we'd be adding more accurate file_dep
and targets
, when at all possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah probably we can add it back. This is likely a leftover of fighting with the doit tasks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I don't know, this task is just here so we can simply install the packages in editable mode...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right: but it would at least depend on:
pyproject.toml
(changingentry_points
,data_files
, and a raft of other things invalidates an editable install)- anything indirectly consumed by
pyproject.toml
(e.g._version.py
or wherever the source of truth is these days)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm planning to have another look at this as part of #684
@@ -20,7 +20,6 @@ runs: | |||
|
|||
- name: Install | |||
shell: bash | |||
if: steps.cache-node-modules.outputs.cache-hit != 'true' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😿 caching node_modules
(provided .eslint
and .prettier
don't muck about in there, as they do by default for some reason) has been really stable, and saves an appreciable real amount of time... meanwhile, without a way to clean out the yarn cache, it just gets bigger, and misses a lot.
it does opens us up for e.g. the svgo
issues, which seem to happen anyway when the runners change their apt
deps, i guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this one was used anyway, the jupyterlab/maintainer-tools/.github/actions/base-setup
action above should already handle caching.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For svgo
maybe we should remove it from the CI / dodo tasks. I don't know if we need to optimize the images all the time, this could be done occasionally when needed. And also setting up a fresh new env almost always leaves the git repo in a dirty state with some icon files being modified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should already handle caching.
... of the ever-expanding, never-pruned ~/.cache/yarn
, which then still requires compiling binaries from source, sometimes, and invoking the solver.
for
svgo
My point was "any crazy node_modules
," but svgo
in specific could be replaced with the stable, but slightly less efficient pure-python scour
. But maybe more closed-form, and would cause less thrash.
Anything that "only gets run sometimes,".... doesn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway that's off topic, I opened #1004 to discuss this more.
@@ -82,7 +79,7 @@ If detected, [`libarchive-c`](https://pypi.org/project/libarchive-c) will be use | |||
better performance, especially when working with archives with many/large assets, | |||
espcially [pyodide](../../python/pyodide.md). | |||
|
|||
If not `libarchive-c` is not detected, python's built-in `zipfile` and `tarfile` modules | |||
If `libarchive-c` is not detected, Python's built-in `zipfile` and `tarfile` modules |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should move away from libarchive-c
: outside of conda/mamba
, it is a pain to install... i don't know what to replace it with, though... the whole idea is to be able to use binary tools for vetted performance and security, but every one of them carries complexity risks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's track that in an issue?
# TODO | ||
# "jupyterlite-core[lab]", | ||
# "jupyterlite-pyodide-kernel", | ||
"jupyterlite-pyodide-kernel >=0.0.4", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not also the compatible lab?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean as a regular plain dependency?
Not sure we need to add it for now since it was not the case previously with the jupyterlite
package? Also there is already a [lab]
extra.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we could indeed include more dependencies as mentioned in #993 (like ipywidgets). Maybe we can first see how it goes and add them later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking here: the "happy path" of one of the most complex dependency issues, relying on the users' package manager of choice to make sys.prefix
whole, will start getting less happy as extensions don't install/solve correctly because of jupyterlab 4... and [extras]
are basically broken.
A future jupyterlab-core
can then depend on jupyterlab >=4,<4.1
, even when we maintain the 3.5
compatible one.
I like widgets for this same reason: we can support ipywidgets >=7.6,<8
, but there's no guarantee all future versions will have compatible jupyterlab_widgets
releases, and getting kernels up to supporting widgets represents a huge amount of effort (right next to arbitrary python packages, and iteratively reducing friction there).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's track that in a separate issue about which package to include in jupyterlite
by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #1003
Getting this one in to unblock other work and we can address follow-ups in other PRs. |
References
Update the dependencies for the
jupyterlite
metapackage.Follow-up to #994.
Part of #993
This will be a follow-up to jupyterlite/pyodide-kernel#23.
Code changes
jupyterlite-core
dependencyjupyterlite-pyodide-kernel
jupyterlab/maintainer-tools/.github/actions/base-setup@v1
(remove some logic already handled by the action)jupyterlite-core
and how to install the Pyodide kernelUser-facing changes
This will ensure end users depending on
jupyterlite
will still get the Pyodide kernel by default for now.Backwards-incompatible changes
None