Fork-specific config

[mikewaters]

@gregarmer

I am trying to reason through providing fork-specific configuration. The stated goal is to carry all configuration in the code, using something resembling travis.yml.

This presents a problem if a single hamster is to be used to build multiple forks of a repo (given that the forks are kept synchronized), and a fork requires custom build instructions or configuration (consider "requires/NN.txt" from our favorite django project). These configurations will need to be stored elsewhere or provided by the caller.

Do you have a preference? My inclination is to allow the repo-stored config file to be Jinja templated, and apply context received from somewhere to that template.

- requires_file: "{{ requirements_filename |default('requirements.pip') }}"

Apparently, salt does this exact thing; we could even leverage https://github.com/saltstack/salt/blob/develop/salt/renderers/jinja.py

If you agree with this approach, then what is your preference for the 'somewhere'? It could be stored config in the hamster, or params from the API build request (though that seems a little dangerous).

[keymholio]

This doesn't answer your question at all, but can we have a hamster.wheel config file?

[gregarmer]

I'm not sure on the answer yet, but another option to consider would be keeping the base configuration in the primary configuration file, and then allowing an override file through an environment variable or the repo owner (user / org) name.

The Jinja suggestion probably provides more power though, so it sounds like a better option right now.

[gregarmer]

@keymholio While that would be insanely relevant, we may have issues with formatting and syntax highlighting systems that use the file extension alone to decide on which lexer to use. It also has potential to create confusion with the new Python wheel packaging format.