As requested by @neersighted in #1611, opening a new issue.

1. Install Poetry 1.2.0
2. poetry config virtualenvs.create false
3. Try to run something using poetry run. Observe that a message “Skipping virtualenv creation, as specified in config file.” is output to stdout:

$ poetry run date 2>/dev/null
Skipping virtualenv creation, as specified in config file.
Tue  6 Sep 16:07:21 UTC 2022

Or try poetry export:

$ poetry export >export.stdout 2>export.stderr
$ cat export.stdout
Skipping virtualenv creation, as specified in config file.
Skipping virtualenv creation, as specified in config file.
Updating dependencies
Resolving dependencies...

Writing lock file
useless-py==1.0.3 ; python_version >= "3.10" and python_version < "4.0" \
    --hash=sha256:27117ffe3044ffeee36af4572c224e445e04878668c45b133cfe606998c73b2a
$ cat export.stderr
The lock file does not exist. Locking.

The way -q affects this is inconsistent. With run it removes the virtualenv message, with export it removes everything, making the command useless (unless -o is specified). And while it’s a step in the right direction, someone can write a script using, for example, poetry run scripts/make-some-json | jq ... and it will work under the default settings but not for someone who has set up the same codebase with virtualenvs.create=false (for example, in a container). You can’t expect developers to add -q to all poetry invocations in scripts just in case at a later point poetry decides to add something to the output.

Suggested resolution: whenever there’s a “main” output (the machine-readable output of poetry export, or poetry run that could be anything) that could be saved into a file, piped etc., don’t add anything to it unless -v is present, in which case write it to stderr. (When the entirety of the output is generated by poetry itself, e. g. with poetry install, there’s no problem with it printing whatever it likes.)