-
Notifications
You must be signed in to change notification settings - Fork 308
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
Running twine tests in dev environment fail and emit PyPI tokens #1121
Comments
Running the tests on 4.0.2 produces a mostly different set of failures, seemingly related to build backend issues. Beginning with 5.0.0, the current set of failures is observed. |
Integration tests broke nearly as soon as you added them over a year ago, but I knew you'd complain if I removed them and you didn't notice any of the pings. Brian ignored them before me and since they very occasionally pass, I've left them. Master is failing now because Tres released an API breaking change in a minor version of pkginfo. I just haven't had time to fix it. Edit Just realized this was a different issue you opened from the one about master tests being broken. |
There appear to be two failure modes here. The first is in |
It looks like when 2afda47 was introduced (#1040), it supersedes the |
I'm unsure the best way forward here. An easy fix might be to disable keyring in tests - mock it out so it always behaves as if there's no password. Another option could be to make |
No strong opinion on the mocking idea, but I think this is likely to cause user confusion (since PyPI and TestPyPI will no longer accept a username at all for package upload, and will always fail hard.) |
@sigmavirus24 or @bhrutledge : Do you have an opinion on how to deal with this scenario? In ddd4ecb, I've drafted "token" as default if unspecified. It addresses the issue, but creates four new test failures (exactly the concern woodruffw raised):
It would be a breaking change to drop that expectation, but it feels like the cleanest approach. It also means that users have more control over their environment, but it means that those reliant on the current hard-coded behavior will need to remove any configured username to retain compatibility. Honestly, that feels best to me because the current approach is masking an unused configuration. It feels wrong for a user (or test) to be explicitly supplying a configuration but it's silently suppressed. I'm also trying to avoid test-only behaviors. I'd like for the tests to exercise the system as closely as possible to how it operates in production, but since it's not possible to override the username or otherwise select a non-default username, the tests are hitting real credentials. It feels like the current design, overriding with a |
In 2c4e4a1, I've committed the changes that allow the tests to pass. Interestingly, not all of 4a2dfb0 had to be reverted. The fixtures in test_settings still retain the behavior that |
Is there an existing issue for this?
What keywords did you use to search existing issues?
tests isolation
Please describe why your using this option
Running
tox
in a clean checkout of twine produces 5 failures:It appears as if the presence of credentials in my keyring is causing tests to fail (and emit my credentials).
Anything else you'd like to mention?
No response
The text was updated successfully, but these errors were encountered: