It's easy to run autogen as a one-off tool with the right flags to generate just the right license + comment header for a new file. However, a particular repository may want to choose standard defaults that all files should follow such that it's trivial to just run autogen foo.py and get just the right format for the header: the right copyright owner, license, and other settings.
In the future, we may add further customizations, e.g., ability to modify the #! line to set different set of default flags, or to run #!/usr/bin/env <binary> rather than simply #!/usr/bin/<binary>, or to avoid automatic C/C++ header guards, or to compute them differently, or to avoid automatic Python boiler plate, etc.
Proposal
Define and implement a config file format, say .autogen.yml that could be stored directly in a repository, version-controlled, that autogen would read and populate its flags' default values from that file, thus enabling:
running autogen without any command line flags could still be meaningful for the repo
overriding any of the repo-default flags is trivial on a per-run basis
This will also enable us to have a single distributable integration with a given editor, since we can just run autogen -s <file> and all the correct settings will be found in the config file. Without such a change, every user needs to modify their editor integration with autogen on a per-repo basis, which is simply unsustainable.1
Thus, the layering of settings would work as follows (from lowest to highest precedence):
autogen built-in defaults
repo-level configuration settings
command-line flags and env vars set by the user
The config file needs to be automatically located within the current directory and parent directories, so that it's seamless to be found, without being specified via a path on the command line.
We can further consider an addition where we may adapt the notion of a root file, past which the parent-directory recursion will not proceed. This can be useful in cases where different directories may have different rules for the default flags, e.g., in the case of imported third-party libraries into a single source tree or other special arrangements.
Related work
For a similar idea in another project, see EditorConfig as well as CI systems like Travis and others use config files in the repo for their purposes.
Footnotes
1 Note that the EditorConfig solution to the per-repo differences in indentation, tabs-vs-spaces, etc. is quite similar to the per-repo differences in licensing, copyright holder, #! lines, comment and test boilerplate, etc.
Motivation
It's easy to run
autogenas a one-off tool with the right flags to generate just the right license + comment header for a new file. However, a particular repository may want to choose standard defaults that all files should follow such that it's trivial to just runautogen foo.pyand get just the right format for the header: the right copyright owner, license, and other settings.In the future, we may add further customizations, e.g., ability to modify the
#!line to set different set of default flags, or to run#!/usr/bin/env <binary>rather than simply#!/usr/bin/<binary>, or to avoid automatic C/C++ header guards, or to compute them differently, or to avoid automatic Python boiler plate, etc.Proposal
Define and implement a config file format, say
.autogen.ymlthat could be stored directly in a repository, version-controlled, thatautogenwould read and populate its flags' default values from that file, thus enabling:autogenwithout any command line flags could still be meaningful for the repoThis will also enable us to have a single distributable integration with a given editor, since we can just run
autogen -s <file>and all the correct settings will be found in the config file. Without such a change, every user needs to modify their editor integration withautogenon a per-repo basis, which is simply unsustainable.1Thus, the layering of settings would work as follows (from lowest to highest precedence):
autogenbuilt-in defaultsThe config file needs to be automatically located within the current directory and parent directories, so that it's seamless to be found, without being specified via a path on the command line.
We can further consider an addition where we may adapt the notion of a
rootfile, past which the parent-directory recursion will not proceed. This can be useful in cases where different directories may have different rules for the default flags, e.g., in the case of imported third-party libraries into a single source tree or other special arrangements.Related work
For a similar idea in another project, see EditorConfig as well as CI systems like Travis and others use config files in the repo for their purposes.
Footnotes
1 Note that the EditorConfig solution to the per-repo differences in indentation, tabs-vs-spaces, etc. is quite similar to the per-repo differences in licensing, copyright holder,
#!lines, comment and test boilerplate, etc.