Update or drop create_config?


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.

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.

What do you think, @sgugger?

UPD: There’s also a small mismatch:

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?

The 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.

1 Like

Thank you for reviewing those PRs and suggesting how to go about create_config!

Here’s what I have in mind:

  1. 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.
  2. 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.
  3. 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.

1 Like

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.