[PATCH v2 2/2] Introduce conf/config.dev for development

[Frédéric Mangano-Tarumi]

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.