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

Update jupyterlite dependencies and docs #1001

Merged
merged 53 commits into from Mar 15, 2023
Merged

Conversation

jtpio
Copy link
Member

@jtpio jtpio commented Mar 10, 2023

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

  • Update jupyterlite-core dependency
  • Depend on jupyterlite-pyodide-kernel
  • Streamline more CI with jupyterlab/maintainer-tools/.github/actions/base-setup@v1 (remove some logic already handled by the action)
  • Test on Python 3.8
  • Update docs to mention jupyterlite-core and how to install the Pyodide kernel

User-facing changes

This will ensure end users depending on jupyterlite will still get the Pyodide kernel by default for now.

Backwards-incompatible changes

None

@github-actions
Copy link
Contributor

lite-badge 👈 Try it on ReadTheDocs

@jtpio
Copy link
Member Author

jtpio commented Mar 10, 2023

Pending jupyterlite/pyodide-kernel#23 and a release of jupyterlite-pyodide-kernel.

@jtpio jtpio added this to the 0.1.0 milestone Mar 10, 2023
@jtpio
Copy link
Member Author

jtpio commented Mar 10, 2023

Since we're requiring Python 3.8+ in jupyterlite-pyodide-kernel (https://github.com/jupyterlite/pyodide-kernel/blob/c3f1d74a48510f4fa39f52b6c04312e946090be7/pyproject.toml#L25), I would say we should just to the same here as well.

Or just test on 3.8 instead of 3.7.

@jtpio
Copy link
Member Author

jtpio commented Mar 13, 2023

OK I think this should be good to go now.

Planning to make a new 0.1.0b19 release of both jupyterlite-core and jupyterlite from the repo after the merge.

Some follow-ups items for later:

@jtpio jtpio marked this pull request as ready for review March 13, 2023 18:01
@jtpio jtpio requested a review from bollwyvl March 13, 2023 18:01
actions=[U.do(*args, cwd=cwd)],
file_dep=file_dep,
name="py:jupyterlite",
actions=[U.do(*metapackage_args, cwd=P.ROOT)],
Copy link
Collaborator

@bollwyvl bollwyvl Mar 13, 2023

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.

Copy link
Member Author

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

Copy link
Member Author

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...

Copy link
Collaborator

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 (changing entry_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)

Copy link
Member Author

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'
Copy link
Collaborator

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Collaborator

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.

Copy link
Member Author

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
Copy link
Collaborator

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.

Copy link
Member Author

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",
Copy link
Collaborator

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?

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Collaborator

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).

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened #1003

@jtpio
Copy link
Member Author

jtpio commented Mar 15, 2023

Getting this one in to unblock other work and we can address follow-ups in other PRs.

@jtpio jtpio merged commit ff49d65 into jupyterlite:main Mar 15, 2023
17 checks passed
@jtpio jtpio deleted the update-packages branch March 15, 2023 07:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants