You can clone this repo and use it as a template.
Once cloning it locally, run:
$ ./bootstrap.sh
This installs requirements, the semi-official, but experimental nbdev VSCode extension, and nbdev git pre-commit hooks. You will be prompted for your sudo password because it installs Quarto, which needs root access by default. ¯\(ツ)/¯
- To get started, open VSCode in this folder:
code .
- When prompted, install the workspace suggested extensions (like Python, Jupyter, etc)
- Then, open the
nbs/index.ipynb
file in VSCode. - VSCode might likely prompt you to install Jupyter. That’s cool.
- Edit the index.ipynb file, and watch as it automatically becomes
your README.md when you run
nbdev_build_docs
.
$ ./scripts/nbdev_preview.sh
The other notebooks automatically get converted to .py files when you
run nbdev_build_lib
.
- To see how that works, open
00_core.ipynb
. - run
nbdev_build_lib
to convert it to a .py file. - Open the
nbdev_vscode_template/core.py
file that was generated. - Put your cursor in the
say_hello
function and press F12 to jump to the definition of that function in your 00_core.ipynb file. (This is feature of the nbdev-vscode extension.) - Put your cursor in the
add_one
function in the notebook and hitF12
and see it jump to your function definition in the .py file.
This repository uses pre-commit hooks to cleanup the notebook before pushing.
Option 1: The simplest way to do things is to run this script to ensure that things are ready to be committed:
./scripts/nbdev_prepare.sh
# Now git commit as always
When you do a git commit in this repo that has pre-commit hooks installed, your new workflow will be as follows:
- pre-commit runs each hook on your staged changes (as in, changes that you git added)
- If a hook changes files – for example, if a commited notebook wasn’t cleaned – pre-commit stops the commit, leaving those changes as unstaged. (This won’t happen if you use nbdev_prepare!)
- You can now stage those changes and make any edits required to get pre-commit to pass
- Redo the git commit, and if it succeeds, your commit will be created.
- Using it in practice isn’t as complicated as it might sound. The best way to figure out if it works for you is to give it a try.
If you have questions, see this documentation about nbdev pre_commit
For more on nbdev usage, follow the nbdev tutorial.
When you push changes to your github repo, you’ll see three actions run.
(These actions are defined inside of .github/workflows
)
test
(this is the main CI step that runs each of your notebooks. A test is just a cell executing without an exception.)Deploy to Github Pages
(builds your Github pages to thegh-pages
branch.)pages-build-deployment
(Automatically run when your gh-pages branch updates, to deploy your built pages to your site. )
If you want to see your Github pages hosted publicly, you’ll want to enable Github Pages in your repo settings.
This README, just like everything else in nbdev, is authored in a notebook. That means we can do cool stuff like run code in the notebook, and have the output show up in the readme, like this:
say_hello("world")
'Hello world!'
Or this:
# Show an image of a cat:
from IPython.display import Image
Image(url="https://www.catster.com/wp-content/uploads/2017/08/A-fluffy-cat-looking-funny-surprised-or-concerned.jpg")
- Figure out how console scripts work in settings.ini and add bootstrap to that.
- Figure out the proper order of setup.py stuff and the bootstrap.sh stuff. (Should bootstrap.sh just be something that setup.py runs? I am a Python noob.)
- Show how to use https://github.com/benbalter/jekyll-auth to use private Github pages for private repos (without having to upgrade to Github Enterprise)
- When the NBDev-VSCode extension gets published, add it as a recommended extension.