On Thu, 16 Nov 2006 15:43:48 -0800 Zac Medico <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Marius Mauch wrote: > > On Thu, 16 Nov 2006 09:33:05 -0800 > > Zac Medico <[EMAIL PROTECTED]> wrote: > > > >> Sure, that's one way to solve that particular problem. However, I feel > >> that command line options are more aesthetically appealing than environment > >> variables (maybe it's just me). > >> > >> Zac > > > > It's just you ;) > > > > Marius > > Do you honestly prefer environment variables over command line options? I > prefer command line options because they are part of a clearly defined > interface. With environment variables, the interface may not be clearly > defined and it's easy for variables to accidentally leak in, affecting > internals in unexpected ways. > > Zac I prefer to have one way to do things, and the system for variables worked quite well so far. Adding CLI overrides on top of that seems not only redundant to me but also potentially confusing (which vars have CLI overrides? where in the incremental stack does the override fit in?). Add that to the already overloaded option system. Besides, if you need this feature on a somewhat regular base it seems easier to me to just export the var once instead of specifying the option on the command line all the time (ok, using DEFAULT_OPTS avoids that, but then you have the same issues you listed above). And last but not least a CLI option is bound to emerge, but this feature can also be useful for other tools. Checking an env var in the config class would enable it implicitly for all users of portage.py, without it everyone would have to basically duplicate the relevant code from emerge. I'm not generally against using CLI options for passing in arguments, but in this case I think it's wrong. Marius -- gentoo-portage-dev@gentoo.org mailing list
