-
Notifications
You must be signed in to change notification settings - Fork 588
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
Import sqlite3 only if used; minor bugfixes #620
Conversation
10fb3e2
to
a6f3243
Compare
a6f3243
to
2f20f98
Compare
6329368
to
0f9081e
Compare
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.
I think we should resist the temptation to bundle multiple fixes into a single PR just so they go in a single release, so I'd like to split this out into two PRs with their own patch release.
The individual changes look fine, but I'd like some tests for them - I'm not at all clear on how we'd test the sqlite3 logic right now, so if we can't think of something then I'm happy to leave it, but the enum change should definitely be tested.
Sure. I just find it frustrating to write competing changelogs for a single proposed version - is there anything I can do to help review go faster? |
0f9081e
to
3cc95a1
Compare
Also unsure how to test this, but pulls have been split. Any other blockers? |
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.
I just find it frustrating to write competing changelogs for a single proposed version
I agree. I think some means of automating changelog aggregation and version management is increasingly necessary. I'm still pondering what the best thing to do is here, but am very open to suggestions.
is there anything I can do to help review go faster?
I think not really - the major blocker on review is just that @alexwlchan and I are both quite busy on other things right now, and we're the main people who could review.
docs/changes.rst
Outdated
|
||
Instead of unconditionally importing ``sqlite3``, Hypothesis now imports it | ||
when a SQLite database is first used. This was the major blocker for BSD | ||
support with default settings. |
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.
I'd probably just say "this allows Hypothesis to work on implementations compiled without sqlite support" or similar. It's not really a major blocker because the fix is just "install sqlite support".
3cc95a1
to
573bc62
Compare
docs/changes.rst
Outdated
|
||
This is a compatibility release: Hypothesis no longer imports ``sqlite3`` | ||
before a SQLite database is first used, so the default settings now work on | ||
Python implementations compiled without sqlite support (eg BSD). |
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.
I refuse to make this a blocking comment and am going to approve the change, but my preferred convention here is "e.g. " rather than "eg" and it would make me happy if you followed. :-)
LGTM. Note that you'll need to rebase against master before it's mergeable. |
And bump the date in the changelog! |
573bc62
to
e67a5bb
Compare
@DRMacIver, after #629 is merged we can rerun the changelog check and merge. |
Still a single import, but this way it's only attempted if you're actually using a sqlite example database.
e67a5bb
to
775084a
Compare
Still a single import, but this way it's only attempted if you're actually using a sqlite example database. IMO it is better to raise an import error if you attempt to use sqlite than to change the database selection logic depending on whether it is installed. Closes #173.