Allow verbose/quiet level to be specified via config file and env var

[McSinyx]

This allows options of action count to be specified via configuration files as well as environmental variables. The affected options include verbose and quiet. If this patch is merged, for example the following will be equivalent:

pip -vvv
PIP_VERBOSE=3 pip

[deveshks]

This would need tests, and also a doc update. (Two places which come to mind are https://pip.pypa.io/en/latest/reference/pip/#console-logging and https://pip.pypa.io/en/latest/user_guide/#environment-variables)

[gutsytechster]

Just some wee corrections.

[McSinyx]

Thanks @gutsytechster. Personally I prefer two-space separated sentences (and . is built into my muscle memory), but indeed consistency is better.

Also it seems CIs (now?) check for merge result, which is really nice!

[McSinyx]

I'm wondering how this should be tested. pip config debug output would be the intuitive way, but it doesn't show the behavior, especially when verbosity and quietness really depend on the log content. How far should I imply on the output of a command?

[McSinyx]

@pfmoore, are the tests in ce9bbe7 sufficient? I dug down a bit further and found out we no longer seem to have tests for config files like we used to (0e5b28e). Edit: I did not look hard enough.

Also, should we accumulate the values in different level, e.g. with verbose=2 in config and PIP_VERBOSE=1 then we'll have verbosity to be 3? My initial intuition tells me that this is quite confusing.

[McSinyx]

Thanks, @xavfernandez! The consistency of my dyslexia is incredible 😄

[xavfernandez]

Why not

Suggested change

	def tmpconfig(option, value, section='global'):
	with NamedTemporaryFile(mode='w', delete=False) as f:
	f.write('[{}]\n{}={}\n'.format(section, option, value))
	name = f.name
	try:
	yield name
	finally:
	os.unlink(name)
	def tmpconfig(option, value, section='global'):
	with NamedTemporaryFile(mode='w', delete=True) as f:
	f.write('[{}]\n{}={}\n'.format(section, option, value))
	yield f.name

[McSinyx]

I spent a solid minute trying to figure out why I wrote it as I did it 😄 Turns out it was to ensure that the file is written to disk (which is warrantied by f.__exit__). I think we can use f.flush() as well although I'm not sure enough about NamedTemporaryFile semantic to tell if that is safe on all platforms.

[pradyunsg]

The file is definitely written on every newline AFAICT, so I think @xavfernandez's suggestion will work well for simplifying this logic. :)

[McSinyx]

FYI writing newline doesn't write to disk (at least not by default), but thanks for raising this up. The best source I can refer to is ISO C99 7.19.3.3 which states:

When a stream is unbuffered, characters are intended to appear from the source or at the destination as soon as possible. Otherwise characters may be accumulated and transmitted to or from the host environment as a block.

When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled.

When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered.

I dig down CPython docs again and found (NamedTemporaryFile passes buffering to open):

buffering is an optional integer used to set the buffering policy. Pass 0 to switch buffering off (only allowed in binary mode), 1 to select line buffering (only usable in text mode), and an integer > 1 to indicate the size in bytes of a fixed-size chunk buffer. When no buffering argument is given, the default buffering policy works as follows:

• Binary files are buffered in fixed-size chunks; the size of the buffer is chosen using a heuristic trying to determine the underlying device’s “block size” and falling back on io.DEFAULT_BUFFER_SIZE. On many systems, the buffer will typically be 4096 or 8192 bytes long.
• “Interactive” text files (files for which isatty() returns True) use line buffering. Other text files use the policy described above for binary files.

So if we set buffering=1 the file would be flushed upon newline, otherwise after a few KiB. However, TextIOWrapper.flush does not seem warranty to flush the filesystem file (or maybe I interpret the comment incorrectly, please don't ask me what the code actually does).

That being said, I'm pretty sure on most platforms it is safe to assume flush would do the job and would not object someone else applying the patch above. Personally I just do know enough to be responsible for such change.

[xavfernandez]

Thanks for your patience ^^

[McSinyx]

Thank you for the merge!