Skip to content
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

Deprecate the use of settings objects as context managers #1327

Closed
Zac-HD opened this issue Jun 13, 2018 · 9 comments
Closed

Deprecate the use of settings objects as context managers #1327

Zac-HD opened this issue Jun 13, 2018 · 9 comments
Labels
legibility make errors helpful and Hypothesis grokable

Comments

@Zac-HD
Copy link
Member

Zac-HD commented Jun 13, 2018

This API was a bad idea and should be removed, leaving settings to be determined by global state or decorators only. Using a settings object as a context manager is somewhat ambiguous (should it happen when the test is defined, or executed? certainly not within a test...) and just plain unnecessary.

@Zac-HD Zac-HD added the legibility make errors helpful and Hypothesis grokable label Jun 13, 2018
@Zac-HD
Copy link
Member Author

Zac-HD commented Jun 14, 2018

I tried just adding note_deprecation(...) to settings.__enter__ in _settings.py, and running the tests to see what breaks - the main task of this issue is to mechanically fix (or delete) our tests anywhere we're using this, and write a minor release note to explain to users that they should stop too.

Of our tests: 1115 failed, 743 passed. Not recommended for new contributors 😭

@alexwlchan
Copy link
Contributor

I have some time for open-source this weekend, I might pick this up if nobody minds?

@Zac-HD
Copy link
Member Author

Zac-HD commented Jun 14, 2018

If you have some time I'd love a review for my open PRs, and after (or before) that this one is all yours.

@alexwlchan
Copy link
Contributor

alexwlchan commented Jun 15, 2018 via email

@Zac-HD
Copy link
Member Author

Zac-HD commented Jun 15, 2018

Whatever works for you, but I'd suggest #1295, #1270, #1304, #1282 as a value-for-effort order. Thanks!

@alexwlchan
Copy link
Contributor

I’m going to have a quick look at this.

@alexwlchan alexwlchan assigned alexwlchan and unassigned alexwlchan Jun 16, 2018
@alexwlchan
Copy link
Contributor

Ah, we use settings as a context manager in engine.py, where I think we do want to scope it to within a single run() method. That seems to be the root of most of the test breakages,

It’s not immediately obvious to me how we unpick it from there, but it’s been a while since I‘ve had to think about this code…

@Zac-HD
Copy link
Member Author

Zac-HD commented Jun 20, 2018

The obvious option to me would be to add a private context manager function _with_settings(s), which does exactly the same thing but isn't public API - the alternative would be to manually pass the object around everywhere, and that gets ugly (and unmaintainable) very quickly.. Then it's just a matter of removing the context manager use from our docs and tests...

Do you still want to do this, or shall I?

@alexwlchan
Copy link
Contributor

Do you still want to do this, or shall I?

I’m doing it. Hopefully at least a WIP PR by the end of the day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
legibility make errors helpful and Hypothesis grokable
Projects
None yet
Development

No branches or pull requests

2 participants