-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Patch for setup.py egg_info issue #5760
Conversation
…here requirementslib is using system python (until better patch can be made).
stdout=sp.PIPE, | ||
stderr=sp.PIPE, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stdout=sp.PIPE, | |
stderr=sp.PIPE, | |
capture_output=True |
% MY_CODE="import subprocess as sp ; sp.run([python, "setup.py"] + args, cwd=target_cwd, stdout=sp.PIPE, stderr=sp.PIPE)"
% echo $MY_CODE | ruff --select=UP022 --fix -
import subprocess as sp ; sp.run([python, setup.py] + args, cwd=target_cwd, capture_output=True)
% ruff rule UP022
# https://beta.ruff.rs/docs/rules/#pyupgrade-up
replace-stdout-stderr (UP022)
Derived from the pyupgrade linter.
Autofix is always available.
What it does
Checks for uses of subprocess.run
that send stdout
and stderr
to a
pipe.
Why is this bad?
As of Python 3.7, subprocess.run
has a capture_output
keyword argument
that can be set to True
to capture stdout
and stderr
outputs. This is
equivalent to setting stdout
and stderr
to subprocess.PIPE
, but is
more explicit and readable.
Example
import subprocess
subprocess.run(["foo"], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
Use instead:
import subprocess
subprocess.run(["foo"], capture_output=True)
References
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was the removal of cwd=target_cwd
intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cclauss intentional, as it seemed unnecessary with the cd(target_cwd)
context manager -- should already be in that directory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well its finally having a good run -- some just turned green.
97c2429
to
713df0c
Compare
This reverts commit e40125e.
Thanks massively. This fixed the problem for me. |
It was discovered that requirementslib uses the sys.executable python rather than the pipenv environment python. Which as @oz123 reminded me should be the same, but due to some weird code paths, it wasn't always the same in my testing when the resolver got invoked as subprocess.
The issue
Fixes #5753
The fix
I don't love the use of the environment variable, but I figured out this was the original intention of how the pipenv <--> requirements lib interface and at some point it got hard-coded to sys.executable in the resolver code which was getting invoked with a different python version at points.
This fixes the problem by ensuring that the correct python of the pipenv environment is being used.
The checklist
news/
directory to describe this fix with the extension.bugfix.rst
,.feature.rst
,.behavior.rst
,.doc.rst
..vendor.rst
. or.trivial.rst
(this will appear in the release changelog). Use semantic line breaks and name the file after the issue number or the PR #.