Idiom for specifying Jupyter-only requirements in a repo

General
1

I have the following situation with regard to packages for use with my JupyterLab notebooks:

  1. packages required whoever my code is used (always_ ...),
  2. packages that are only needed on Binder (binderonly_ ...) , and
  3. packages that are only needed when using a Jupyter notebook elsewhere, e.g., locally on in a cloned repo (jupyteronly_ ...)

Binder has an elegant way of handling this automatically, in with a requirements.txt containing all (and only) 1,

always_pkgA
always_pkgB
...

and a .binder/requriments.txt containing all (and only, 2,

-r ../requriments.txt
binderonly_pkgX
binderonly_pkgY
...

It’s tempting to replace this approach for local or cloned repo uses of JupyterLab with something like a jupyter/requirements.txt containing

-r ../requriments.txt
jupyteronly_pkgP
jupyteronly_pkgQ
...

and special instructions to

pip install -r jupyter/requirements.txt

rather than the usual

pip install -r requirements.txt

when using Jupyter locally.

But I wonder — is there a better approach, or an idiom that people use for this kind of scenario?

2

I think it’s a pretty common to have multiple dependent requirements[-context].txt files, e.g. requirements-dev.txt for development and requirements-test.txt (sometimes the dev- goes first, I don’t know which is more popular!). Extending that pattern to any other context like requirements-jupyter.txt seems sensible enough and should be reasonably well understood. I would probably make it a top-level file next to requirements.txt instead of making a directory for it, but that’s a fairly minor detail. It could get hairy if you have more than a few contexts to consider, but if it’s just a couple I think it works well.

The main alternative I see is if your tool is a Python package, it can have extras_require, so that you would do e.g. pip install mypackage[jupyter] or pip installl -e '.[jupyter]' for a local dev install.

2 Likes
3

@minrk Very helpful, thanks!