I’ve been working on a CLI to spin up a new nbdev project. It would also make a settings.ini with some default values.
Ideally, I wanted to be able just run one cli command (
nbdev_new) and then run
nbdev_build_lib without any customization at all, if possible. Or at least have some sane defaults in settings.
There’s a handy func
create_config that creates and saves a
settings.ini. But it’s missing some fields (title, description, etc). I’ve managed to break
nbdev_new with it, but fixed it here.
create_config is actually never used, except in nbdev_new, until #55 is merged.
Ideally, I would like
create_config to make a config that has all the required fields, but also retains the comments that are in nbdev_template settings.ini. I’d be happy to do that, if you think it makes sense.
I can also move it to a separate notebook (it’s in imports.py, which I think is the only python file not generated from notebooks?), but I need some guidance on whether to move all the config functionality, or keep the core stuff in imports.py.
Alternatively, if it’s no longer needed and we decide to not generate a new config on
nbdev_new, we could just nuke
What do you think, @sgugger?
UPD: There’s also a small mismatch:
"Store the basic information for nbdev to work"
def __init__(self, cfg_name='settings.ini'):
cfg_path = Path.cwd()
while cfg_path != Path('/') and not (cfg_path/cfg_name).exists(): cfg_path = cfg_path.parent
self.config_file = cfg_path/cfg_name
assert self.config_file.exists(), "Use `Config.create` to create a `Config` object the first time"
self.d = read_config_file(self.config_file)['DEFAULT']
The error message on the assertion references
Config.create, wheres it’s actually called
create_config. I can fix that in the same PR while we’re at it.
Reading the code again, I don’t see a reason not to move whole Config class (plus create_config) into a 0*_config.ipynb. Am I missing anything?
create_config is used independently by people that want to turn a notebook in one script, so this function is used. For the rest:
- okay to make the config created more like the template
- of course the error message should point to the right function
- make sure to not break the existing behavior of
create_config is possible
Note that the very first notebook needs to define the command to export notebooks, so Config can’t be in its own notebook before.
Thank you for reviewing those PRs and suggesting how to go about create_config!
Here’s what I have in mind:
- Create a
settings.ini.example tempalte file in
nbdev repo and use it as a template to generate config, with
$-notation for substitutions. That way, we can generate a full config with spacing and comments in it, and without requiring
nbdev_template repo to be fetched. This will ensure
create_config works in any environment, with or without the template project.
- Use string Template class to set the config values in
create_config. I don’t particularly love $-syntax, but it’s a templating engine built into Python’s stdlib, so no new requirements will be necessary.
- Test that
nbdev_new, assuming the user has a valid .gitconfig, spits out a
settings.ini that works for both
nbdev_build_docs without errors by calling those functions within the notebooks, so that
nbdev_test_nbs will verify the config consistency.
There’s a problem with this approach:
- If the user generates a github repo from the template to bootstrap their projects, they don’t get the autogenerated config. That’s fair.
- If the user users
nbdev_new to bootstrap their project, that will generate a config from
nbdev repo. If the template project repo changed the settings.ini provided with the template, those changes will get overwritten. Essentially, there will be two versions of the bootstrapped config example. That might be confusing for devs, and that might be confusing for us to maintain.
One workaround would be to:
- not create a separate template in
- and not use
create_config at all for this purpose.
- Add another function that would take a template repo settings.ini, and put some default values right there. I won’t be able to use Template library, but I can do the same thing with a few regex.
That way, we won’t need to maintain two different versions of a starter config file, and create_config won’t be affected at all. The downside will be that it’ll add another function to process the config file and add values into it, and it won’t be as elegant as just running a template substitution.
Since this is not an urgent change, I’ll think about it for a bit more and ping you before moving forward with it. I’ll use nbdev myself a bit more to get a better feel of what makes sense to add and what doesn’t. I’ll put together a prototype of a solution to this by next weekend.
Guys, I got a bit too excited about
fast_template and worked on a small feature there on my free time.
I’m still going to take care of this, but it’ll likely take a week or two more.