i've always thought of blog posts as a means, not an ends.
my dream has always been content that myself and others can execute themselves.
often this goal has been hindered by the need for infrastructure.
advances in the jupyterlite have made it possible to realize this vision without infrastructure.
# `jupyterlite` blog integration
i've always thought of blog posts as a means, not an ends.
my dream has always been content that myself and others can execute themselves.
often this goal has been hindered by the need for infrastructure.
advances in the `jupyterlite` have made it possible to realize this vision without infrastructure.
`jupyterlite` is jupyterlab running completely in the browser without the need for a local server.
this means that folks can redirect from a static post into an interactive version they can try themselves.
## `jupyterlite` notebooks are different
when working with a standard jupyter implementation we are interacting with a server within an implicit environment. when we write our notebooks we assume that we can import modules because they are in our environment. however, in `jupyterlite` we need to explicitly define our dependencies for every notebook.
we define our dependencies by inserting the `pip` line magic:
%pip install my dependencies
this statement is superfluous under normal circumstances so it doesn't need to exist in the source.
instead we use the `depfinder` project to infer the projects imported by our notebook.
the inferred dependencies are then inserted in to the first line of the first code cell of the notebook.
i've always thought of blog posts as a means, not an ends.
my dream has always been content that myself and others can execute themselves.
often this goal has been hindered by the need for infrastructure.
advances in the
jupyterlite
have made it possible to realize this vision without infrastructure.
jupyterlite
is jupyterlab running completely in the browser without the need for a local server.
this means that folks can redirect from a static post into an interactive version they can try themselves.
when working with a standard jupyter implementation we are interacting with a server within an implicit environment. when we write our notebooks we assume that we can import modules because they are in our environment. however, in
jupyterlite
we need to explicitly define our dependencies for every notebook.
we define our dependencies by inserting the
pip
line magic:
%pip install my dependencies
this statement is superfluous under normal circumstances so it doesn't need to exist in the source.
instead we use the
depfinder
project to infer the projects imported by our notebook.
the inferred dependencies are then inserted in to the first line of the first code cell of the notebook.
## the `doit lite` implementation
in the code that follow we define a `doit` task that:
1. builds a `jupyterlite` site for this blog
2. make the dependencies compatible with `jupyterlite`
deftask_lite():"""build the jupyter lite site and append requirements"""returndict(actions=["jupyter lite build --contents tonyfast --output-dir site/run",(set_files_imports,(pathlib.Path("site/run/files"),))],clean=["rm -rf site/run"])importtyping,tonyfast,pathlib,textwrap,re,json