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.
The idea
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 create_config.
class Config:
"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']
add_new_defaults(self.d, self.config_file)
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?
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_lib and 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 setttings.ini.example in 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 nbdev repo,
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.