如何在git中组织python项目？

Question

I have a python project A with module name config which include a config.yaml file. This project is used as a template for others to use and update the config.yaml based on their need. I want these users to fork my git project and make their updates on their fork and be able to get updates to the template when one available. But, I don't want to overwrite the config file as they pull the changes from the master project to their fork. How to solve this?

My_app
  MyConfigModule
     __init__.py
     config_helper.py
     config.yaml
  myAppModule
    __init__.py
    myModule.py

Answer 1

First of all, separate code and configuration. The whole code should reside in My_app and not be touched by users, but only developers, whereas the configuration can sit in the root directory.

You have multiple options how you want to separate default and actual configuration:

Have a default configuration and allow the user to set up their local configuration . The user has to create a config.yaml file themselves. For instance, bash (and many other programs) reads its configuration from /etc/bash.bashrc and then gets updated from ~/.bashrc . The downside of this approach is that you need to implement a configuration merging mechanism. This is a good idea if some part of the configuration is fairly static/complex (say, program settings or transformation rules), but another part often needs to be overwritten (user name / email address).

Require the user to copy config.default.yaml to config.yaml . On program installation or running when config.yaml is not present, you can either throw an error with an explanation of how to copy, silently fall back to the default configuration, or copy the default configuration to config.yaml and then continue on. You can put a lot of documentation into the default configuration, but the downside will be a long config file. For instance, php's default configuration is 2000 lines long.

Prompt the user for the most important (or all) configuration options and write a small configuration file, like debian's debconf. This is a good idea if your program has an interactive UI.

You can mix these options, for instance prompt the user for the most important options and rely on the default configuration, or copy over a long default configuration with slight modifications after prompting the user.

In all of these cases, you want to include config.yaml in your gitignore and not check one in. The default configuration file should be placed at the top level of your repository if you expect the user to copy it manually.