Lukas Fleischer [2020-06-02 17:40:23 -0400]
On Tue, 02 Jun 2020 at 08:41:28, Frédéric Mangano-Tarumi wrote:
Developers need to set AUR_CONFIG to spawn aurweb. If we introduced it earlier like \u201cDefine the path to you configuration: export AUR_CONFIG="\u2026"\u201d, I think it should fit.
That's better, even though I still don't believe it's more useful than just saying, config.defaults here. New users might set things up, then go back to the config the next day without knowing about $AUR_CONFIG anymore.
Saying config.defaults makes it look like it’s hard-coded, without further help. However, I agree with you it’s the simplest option. I’d add an extra “See aurweb/config.py for details.” if you don’t mind.
As you implied though, using anything other than conf/config is madness. How about making aurweb.spawn set AUR_CONFIG to, by order of preference:
1. $AUR_CONFIG, if already defined, 2. $PWD/conf/config, if it exists, 3. $parent/conf/config where $parent is the nearest parent directory such that the file exists.
Sounds reasonable. I would prefer to infer the path from the location of the script itself (__file__) instead of (2) and (3) though.
I’m not sure about __file__ because it gets complicated if the package is installed in a venv or something. We won’t implement that now anyway, so let’s talk about it another day. Same for AUR_ROOT.
In config.defaults, we use newlines only between sections, but that doesn\u2019t leave much room for documentation. Interleaving comments with variables like I did below is okay only because the section is tiny. If the file grew bigger, I wish the norm was \u201cblock of documentation + set of correlated variable definitions + new line\u201d. Sections would need a special comment to make them visible, like a ruler or a frame.
I would hope that each section would correspond to exactly one set of correlated variable definitions, so we would not need this. I am aware that that's currently not the case though.
Actually I meant a stronger correlation, like variables that share the same documentation because that would make no sense to document them individually. See /etc/php/php.ini for the kind of layout I had in mind. There’s an empty line between every variable, and the file would be unreadable without it. I’ll apply that style but feel free to drop the empty lines from my patch without notice if you don’t like them.