Perhaps an individual catalog doesn't need to use the output-repository structure that supernovae does. For example, the catalog may not version-track the output files at all, they may all be contained in a single repository, or perhaps they want to keep the output in the same repository as the code itself.
Instead of requiring the repos.json file and associated methods, we can just require the necessary API methods. i.e. instead of get_repo_output_file_list() (which is used by the delete_old_entry_files() method --- and associated task), require a more general get_output_file_list() which can store/construct those files in any (reasonable) way they wish.
Perhaps an individual catalog doesn't need to use the output-repository structure that
supernovae
does. For example, the catalog may not version-track the output files at all, they may all be contained in a single repository, or perhaps they want to keep the output in the same repository as the code itself.Instead of requiring the
repos.json
file and associated methods, we can just require the necessary API methods. i.e. instead ofget_repo_output_file_list()
(which is used by thedelete_old_entry_files()
method --- and associated task), require a more generalget_output_file_list()
which can store/construct those files in any (reasonable) way they wish.