-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Post-mortem for broken web3 4.7.0 release. #1053
Comments
To prevent this in the future, a requirement for setuptools 36.2.0 or greater could be added to setup.py: e.g.
|
@dylanjw Mirroring what I said on gitter. Bonus: Also run tests against other |
It would bee cool if the wheel could be tested before it gets uploaded to pypi. Maybe the test script you are describing could be broken into 2. A script the detects pypi updates and runs tests across different projects to check for broken dependency issues. Another set of tests that run as part of the build script before uploading the wheel to pypi. |
yeah, you're right. Tests need to run pre-relase with the newly created wheel and post-release across repositories.
If |
Spent some time looking, and havent found a convenient post-release hook from pypi. The closest I have found is libraries.io that will send you an email when a dependency has a new version. |
I think it would be sufficient to add Regarding @voith suggesting about testing the builds: I don't think the complexity justifies the protection it would offer. Complexity is likely to be a non-trivial as it will have to work across OSX/Linux, as well as across python versions. It could easily pass locally but fail for others due to differences in python version and platforms. To prevent some of these false positives, our testing scripts could test across multiple python versions, etc, but this is why I don't think the complexity is justified by the protection it offers. |
I agree, especially about the post-deployment hook. I've seen something like that implemented, and it's really hard to tell the difference between a downstream failure and a web3 failure, which adds a lot of noise to deployment. I do think there might be value in a smoke test in a local pre-deployment install from the built wheel. |
Well, l I didn't mean to run an entire integration test-suite. |
ethereum/eth-tester#127: Yet another instance of dependency hell. |
see ethereum#1053 added feature for inputing block_identifier in eth_estimateGas command variable inputs in estimateGas and tests formatter for block_identifier and passing tests added feature for inputing block_identifier in eth_estimateGas command variable inputs in estimateGas and tests passing lint
see ethereum#1053 added feature for inputing block_identifier in eth_estimateGas command variable inputs in estimateGas and tests formatter for block_identifier and passing tests added feature for inputing block_identifier in eth_estimateGas command variable inputs in estimateGas and tests passing lint
see ethereum#1053 added feature for inputing block_identifier in eth_estimateGas command variable inputs in estimateGas and tests formatter for block_identifier and passing tests added feature for inputing block_identifier in eth_estimateGas command variable inputs in estimateGas and tests passing lint
See #1052
It was discovered that web3 4.7.0 would attempt to install pypiwin32 on all
platforms when installed from pypi with pip whereas a local install with setup.py or
the built tar.gz package did not.
Ref:
setuptools had a bug where environment markers get stripped from the wheel's
MANIFEST.
I had started out building with the broken package with pip version 9.0.3 and
setuptools 28.8.0. (doh!)
Upgrading pip was not sufficient to fix the issue:
After upgrading setuptools the MANIFEST file included in the wheel contains the
environment markers.
The text was updated successfully, but these errors were encountered: