The pre-commit hook is designed around deleting all previously existing generated files and then generating new ones. If the end result is only a modification or deletion of existing files, this change will be noted by pre-commit and trigger hook failure, and developers may then simply stage the new changes and proceed. If, however, the hook produces new files, for instance if a new file key or matrix entry is added to dependencies.yaml, the file creation will not be treated as a failure of the hook. In order to remedy this, we need to modify rapids-dependency-file-generator to return a nonzero exit code if it produces new files. If we do not want to have dfg always behave this way (e.g. if we expect to script with it outside of pre-commit and don't want to be stopped by nonzero exit codes in some cases) we could either use a command line argument or simply provide an additional command line entry point just for the pre-commit hook.
The most elegant solution here would be to use GitPython to check the list of untracked files before and after, but we could also use the same os.walk + text parse strategy used for cleaning to get the list of generated files before and after. I assume that we would prefer that to introducing the GitPython dependency since we did so for the cleaning.
The pre-commit hook is designed around deleting all previously existing generated files and then generating new ones. If the end result is only a modification or deletion of existing files, this change will be noted by pre-commit and trigger hook failure, and developers may then simply stage the new changes and proceed. If, however, the hook produces new files, for instance if a new file key or matrix entry is added to dependencies.yaml, the file creation will not be treated as a failure of the hook. In order to remedy this, we need to modify rapids-dependency-file-generator to return a nonzero exit code if it produces new files. If we do not want to have dfg always behave this way (e.g. if we expect to script with it outside of pre-commit and don't want to be stopped by nonzero exit codes in some cases) we could either use a command line argument or simply provide an additional command line entry point just for the pre-commit hook.
The most elegant solution here would be to use GitPython to check the list of untracked files before and after, but we could also use the same os.walk + text parse strategy used for cleaning to get the list of generated files before and after. I assume that we would prefer that to introducing the GitPython dependency since we did so for the cleaning.