The prose is a requirement to maintain sanity. The solution is at the bottom.
nbdev_new refused to run, not because it couldn’t find the private repo like the first time, but because it wanted a name:
REPONAME % nbdev_new
usage: nbdev_new [-h] [--template_git_repo TEMPLATE_GIT_REPO] name
nbdev_new: error: the following arguments are required: name
So I searched and started thinking: maybe I should just put one block on top of another instead of trying to push a button? IE: could setting up NBDev be as simple as drag and dropping the template? This post by J. Howard suggests so. Unfortunately it’s over a year old so here’s hoping nothing changed.
A couple thoughts here on what made this all so confusing. The docs say create a PAT. The link from Husain, who made/works on the entire github actions/workflow thing at the root of this, suggests to use an “encrypted secret”. Do we use both? I assume only the second. But the link shows 3 different types of encrypted secret. No word on which is appropriate. Also the PAT linked from the docs: GitHub’s docs say it only works with HTTPS repos… so if you tried to have good security and use SSH it won’t work? That doesn’t sound good. The biggest confusion is what looks like a cold-start / chicken-and-egg situation. There’s no github action/workflow until NBDev makes one, but NBDev can’t make one if it can’t find the repository… but it won’t be able to find the repo if there’s no secret key in the action/workflow… hence the confusion.
As a recap, what I did first was create a PAT, and when that didn’t work I made a repo encrypted secret. I don’t know how you connect those variables to NBDev, and the error message NBDev gives in the terminal (in the repo’s root directory, without any arguments) is that it’s missing a name.
unless what you’re supposed to do is copy-paste nbdev_template into your repo, then go into its workflow file (.github/workflows/main.yml) and add the PAT there. Though what I’m understanding now is the PAT is made obsolete by a repository encrypted secret, so maybe you put that in via its $VARIABLENAME instead?
Trying to go backwards
I also wondered… the new failure mode (
nbdev_new wanting a name) started after I added a personal access token (PAT) as per the NBDev docs and a repository encrypted secret as per the suggestions in Husain’s link above. Hard deleting the local repo directory via
rm -rf and re-cloning didn’t get the first failure mode (
nbdev_new unable to find the private repo) back, and I tried twice to make sure. I didn’t edit any workflow / actions files yet so I don’t know where an interaction would be coming from, but if that’s the only thing I changed: what if I deleted the PAT and the repo encrypted secret?
→ No, deleting either or both changed nothing. Likely because I didn’t put them in a workflow file yet.
Goal: integrate NBDev into a private repository
nbdev_new command cannot find private repositories.
- copy-paste the nbdev_template repository into your private repo.
Exceptions: omit the .git folder; add the contents of .gitignore to your own.
- add a “_data” folder in the “docs” folder.
- Thanks to enryH & paulkarayan in this issue thread. Otherwise when running
nbdev_build_lib NBDev won’t be able to create the “topnav.yml” file. (I didn’t have this problem last time I tried using NBDev a year or so ago, and I made sure to be up to date with
conda install -c fastai nbdev. I also think you have to delete topnav.yml if you change your repo’s name.)
- Continue with normal NBDev setup: running
nbdev_install_git_hooks and editting settings.json.
This likely doesn’t solve NBDev not being able to find the repo, and I expect that’ll break workflows / actions, so you’ll have to look into how to add either a PAT or Encrypted Secret environment variable to NBDev’s workflow file. But this does get NBDev basically working. If/when I find out how to get the variables working, I’ll update this post. And if anyone knows how it works, please feel free to share.