You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
hypothesis is listed as a dev dependency in Pipfile, which means it's only needed for development, but not for using Potku. This should be fine, but it causes problems when creating a bundle for distribution: the bundling script uses the release configuration, but it also runs the unit tests. As hypothesis is a testing library, all tests that require it fail, causing the bundling to fail.
Add hypothesis to normal dependencies. Tests will work, but it'll get included in the release build.
Skip tests that use hypothesis when creating the bundle. Tests won't fail and hypothesis will not be added to the release build, but some tests won't be run.
Configure the bundling script to run the tests using dev dependencies. Tests will be run, but this will slow down the bunding because two pipenvs will be created. Also, I don't have the time to figure out how to do this.
The first option is the easiest and won't cause gaps in test coverage, so I think I'll pick that one for now. Someone else could look into the third option later on. Option two seems bad all-around.
The text was updated successfully, but these errors were encountered:
Description
hypothesis
is listed as a dev dependency in Pipfile, which means it's only needed for development, but not for using Potku. This should be fine, but it causes problems when creating a bundle for distribution: the bundling script uses the release configuration, but it also runs the unit tests. Ashypothesis
is a testing library, all tests that require it fail, causing the bundling to fail.hypothesis
was added in PR #243 for issue #214.Resolution
I see three possible solutions:
hypothesis
to normal dependencies. Tests will work, but it'll get included in the release build.hypothesis
when creating the bundle. Tests won't fail andhypothesis
will not be added to the release build, but some tests won't be run.The first option is the easiest and won't cause gaps in test coverage, so I think I'll pick that one for now. Someone else could look into the third option later on. Option two seems bad all-around.
The text was updated successfully, but these errors were encountered: