-
-
Notifications
You must be signed in to change notification settings - Fork 212
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
Remove Warning/Error messages when using build
#1034
base: main
Are you sure you want to change the base?
Conversation
res_build = subprocess.run( | ||
[sys.executable, "-m", "build", "-nx"], | ||
cwd=wd.cwd, | ||
capture_output=True, | ||
) | ||
assert res_build.returncode == 0 | ||
# Maybe there is a cleaner way to use caplog? | ||
assert not res_build.stderr |
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.
Is there a better way to run and check this?
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.
A hack that might be reasonable would be a fake object directly passed to the integration function
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.
You mean instead of python3 -m build
? I don't think that will end up well because what we want to test here is how build
creates the sdist and from the sdist creates the wheel, and in both steps setuptools-scm
is called with different "sources".
Another option I was thinking is calling build.__main__.main
directly? Then all of the context should be preserved and the caplog
should in principle work?
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.
as far as i remember, build has to start sub-processes for a build
so currently have no idea for a clean solution
Basically when running
python3 -m build
on a perfectly valid project, we find ourselves surprised by unnecessary warning and error messages, namely:See the linked issue for more context on why these messages occur. This PR is trying to eliminate those messages, but first I am writing a test to reproduce a common environment. Thanks to @Mr0grog for the help debugging this issue
TODO:
build
messagesCloses #987