-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unsolicited messages output to stdout #6427
Labels
kind/bug
Something isn't working as expected
Comments
rdaysky
added
kind/bug
Something isn't working as expected
status/triage
This issue needs to be triaged
labels
Sep 6, 2022
Some or more of the MRs welcome, I'm sure. |
neersighted
added a commit
to neersighted/poetry
that referenced
this issue
Sep 6, 2022
This is a quick fix to avoid polluting stdout unexpectedly when Poetry's environment management comes into play. It's apparent from how much the complexity of this file has grown that this needs to be refactored moderately, as well as each major class deserving its own source file. Future work should also include a rethink of how IO objects are passed around the codebase, how we reason about verbosity at a function level, and how code is re-used -- one command may wish to output to stdout, but if that code is reused by another command, the calculus of what is command output and what is informative (or even needs to be hidden/shown based on verbosity level) changes. Work on output would likely have to be fairly comprehensive and invasive, but things have grown complex enough that a top-down design pass is likely the best route. Regardless, this is a simple change today, and low risk. Resolves python-poetry#6427.
neersighted
added a commit
to neersighted/poetry
that referenced
this issue
Sep 6, 2022
This is a quick fix to avoid polluting stdout unexpectedly when Poetry's environment management comes into play. It's apparent from how much the complexity of this file has grown that this needs to be refactored moderately, as well as each major class deserving its own source file. Future work should also include a rethink of how IO objects are passed around the codebase, how we reason about verbosity at a function level, and how code is re-used -- one command may wish to output to stdout, but if that code is reused by another command, the calculus of what is command output and what is informative (or even needs to be hidden/shown based on verbosity level) changes. Work on output would likely have to be fairly comprehensive and invasive, but things have grown complex enough that a top-down design pass is likely the best route. Regardless, this is a simple change today, and low risk. Resolves python-poetry#6427.
neersighted
added a commit
that referenced
this issue
Sep 6, 2022
This is a quick fix to avoid polluting stdout unexpectedly when Poetry's environment management comes into play. It's apparent from how much the complexity of this file has grown that this needs to be refactored moderately, as well as each major class deserving its own source file. Future work should also include a rethink of how IO objects are passed around the codebase, how we reason about verbosity at a function level, and how code is re-used -- one command may wish to output to stdout, but if that code is reused by another command, the calculus of what is command output and what is informative (or even needs to be hidden/shown based on verbosity level) changes. Work on output would likely have to be fairly comprehensive and invasive, but things have grown complex enough that a top-down design pass is likely the best route. Regardless, this is a simple change today, and low risk. Resolves #6427.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As requested by @neersighted in #1611, opening a new issue.
poetry run
. Observe that a message “Skipping virtualenv creation, as specified in config file.” is output to stdout:Or try
poetry export
:The way
-q
affects this is inconsistent. Withrun
it removes the virtualenv message, withexport
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
, orpoetry 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. withpoetry install
, there’s no problem with it printing whatever it likes.)The text was updated successfully, but these errors were encountered: