pax_global_header 0000666 0000000 0000000 00000000064 13541036175 0014517 g ustar 00root root 0000000 0000000 52 comment=195ac07c1bf9c955a12a9a54523ef5ced9e64e23
hypothesis-hypothesis-python-4.36.2/ 0000775 0000000 0000000 00000000000 13541036175 0017526 5 ustar 00root root 0000000 0000000 hypothesis-hypothesis-python-4.36.2/.flake8 0000664 0000000 0000000 00000000642 13541036175 0020703 0 ustar 00root root 0000000 0000000 [flake8]
exclude =
compat.py,
hypothesis-python/src/hypothesis/vendor/*,
test_reflection.py,
test_imports.py,
hypothesis-python/tests/py2/*,
test_lambda_formatting.py
ignore = F811,D1,D205,D209,D213,D400,D401,D412,D413,D999,D202,E203,E501,W503
# Use flake8-alfred to forbid builtins that require compatibility wrappers.
warn-symbols=
bytes=Instead of bytes(), use hbytes() or binary_type
hypothesis-hypothesis-python-4.36.2/.gitattributes 0000664 0000000 0000000 00000000176 13541036175 0022425 0 ustar 00root root 0000000 0000000 * text eol=lf
# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary
*.gif binary
hypothesis-hypothesis-python-4.36.2/.gitignore 0000664 0000000 0000000 00000000533 13541036175 0021517 0 ustar 00root root 0000000 0000000 # misc (editors, file systems, etc)
*.swo
*.swp
.idea
.vagrant
.DS_Store
.hypothesis
.vscode/
# generic build components
.runtimes
# python
*.pyc
*.pyo
venv*
.cache
.pytest_cache
.mypy_cache
docs/_build
*.egg-info
_build
.tox
.coverage
.pypirc
htmlcov
build
dist
.doctrees/
# encrypted files
secrets.tar
secrets
# Rust build targets
target
hypothesis-hypothesis-python-4.36.2/.isort.cfg 0000664 0000000 0000000 00000000664 13541036175 0021433 0 ustar 00root root 0000000 0000000 [settings]
known_third_party = attr, click, dateutil, django, dpcontracts, flaky, lark, numpy, pandas, pytz, pytest, pyup, requests, scipy, unicodenazi, yaml
known_first_party = hypothesis, tests
add_imports = from __future__ import absolute_import, from __future__ import print_function, from __future__ import division
multi_line_output = 3
include_trailing_comma = True
force_grid_wrap = 0
combine_as_imports = True
line_length = 88
hypothesis-hypothesis-python-4.36.2/.pyup.yml 0000664 0000000 0000000 00000000375 13541036175 0021331 0 ustar 00root root 0000000 0000000 requirements:
- requirements/tools.txt:
updates: all
pin: True
- requirements/test.txt:
updates: all
pin: True
- requirements/coverage.txt:
updates: all
pin: True
schedule: "every week on monday"
search: False
hypothesis-hypothesis-python-4.36.2/.readthedocs.yml 0000664 0000000 0000000 00000000042 13541036175 0022610 0 ustar 00root root 0000000 0000000 requirements_file: .rtfd-reqs.txt
hypothesis-hypothesis-python-4.36.2/.rtfd-reqs.txt 0000664 0000000 0000000 00000000030 13541036175 0022245 0 ustar 00root root 0000000 0000000 hypothesis-python/[all]
hypothesis-hypothesis-python-4.36.2/.travis.yml 0000664 0000000 0000000 00000002363 13541036175 0021643 0 ustar 00root root 0000000 0000000 language: c
sudo: false
env: PYTHONDONTWRITEBYTECODE=x
os:
- linux
branches:
only:
- "master"
cache:
apt: true
directories:
- $HOME/.cargo
- $HOME/.rustup
- $HOME/.gem
- $HOME/.cache/pip
- $HOME/wheelhouse
- $HOME/.stack
- $HOME/.local
- vendor/bundle
env:
global:
- BUILD_RUNTIMES=$HOME/.runtimes
- FORMAT_ALL=true
jobs:
include:
# Prechecks that we want to run first.
- stage: precheck
env: TASK=check-whole-repo-tests
- env: TASK=lint
- env: TASK=lint-ruby
- env: TASK=check-format
- env: TASK=check-rust-tests
- stage: main
env: TASK=check-coverage
- env: TASK=check-py27
- env: TASK=check-py36
sudo: required
dist: xenial
- env: TASK=check-ruby-tests
- env: TASK=check-django111
- env: TASK=check-pandas24
- stage: deploy
env: TASK=deploy
script:
- ./build.sh
matrix:
fast_finish: true
stages:
- precheck
- main
- extras
- name: deploy
if: type = push
notifications:
email:
recipients:
- david@drmaciver.com
on_success: never
on_failure: change
addons:
apt:
packages:
- libgmp-dev
- shellcheck
hypothesis-hypothesis-python-4.36.2/CITATION 0000664 0000000 0000000 00000001242 13541036175 0020662 0 ustar 00root root 0000000 0000000 Please use one of the following samples to cite the hypothesis version
(change x.y to the version you are using) from this installation.
You may wish to include the DOI, https://doi.org/10.5281/zenodo.1412597
Text:
[Hypothesis] Hypothesis x.y, 2018
David R. MacIver, https://github.com/HypothesisWorks/hypothesis
BibTeX:
@misc{Hypothesisx.y,
title = {{H}ypothesis x.y},
author = {David R. MacIver},
year = {2018},
howpublished = {\href{https://github.com/HypothesisWorks/hypothesis}{\texttt{https://github.com/HypothesisWorks/hypothesis}}},
}
If you are unsure about which version of Hypothesis you are using run:
`pip show hypothesis` for the Python version.
hypothesis-hypothesis-python-4.36.2/CODEOWNERS 0000664 0000000 0000000 00000000366 13541036175 0021126 0 ustar 00root root 0000000 0000000 # Engine changes need to be approved by DRMacIver, as per
# https://github.com/HypothesisWorks/hypothesis/blob/master/guides/review.rst#engine-changes
/conjecture-rust/ @DRMacIver
/hypothesis-python/src/hypothesis/internal/conjecture/ @DRMacIver
hypothesis-hypothesis-python-4.36.2/CODE_OF_CONDUCT.rst 0000664 0000000 0000000 00000005165 13541036175 0022544 0 ustar 00root root 0000000 0000000 ---------------
Code of conduct
---------------
Hypothesis's community is an inclusive space, and everyone in it is expected to abide by a code of conduct.
This applies in issues, pull requests, etc. as well as in the various Hypothesis community spaces.
At the high level the code of conduct goes like this:
1. Be kind
2. Be respectful
3. Be helpful
While it is impossible to enumerate everything that is unkind, disrespectful or unhelpful, here are some specific things that are definitely against the code of conduct:
1. -isms and -phobias (e.g. racism, sexism, transphobia and homophobia) are unkind, disrespectful *and* unhelpful. Just don't.
2. All software is broken. This is not a moral failing on the part of the authors. Don't give people a hard time for bad code.
3. It's OK not to know things. Everybody was a beginner once, nobody should be made to feel bad for it.
4. It's OK not to *want* to know something. If you think someone's question is fundamentally flawed, you should still ask permission before explaining what they should actually be asking.
5. Note that "I was just joking" is not a valid defence.
6. Don't suggest violence as a response to things, e.g. "People who do/think X should be Y-ed".
Even if you think it is obvious hyperbole and that it's very clear that no actual threat is meant,
it still contributes to a culture that makes people feel unsafe.
~~~~~~~~~~~~~~~~~~~~~~~~
Resolution of Violations
~~~~~~~~~~~~~~~~~~~~~~~~
David R. MacIver (the project lead) acts as the main point of contact and enforcer for code of conduct violations.
You can email him at david@drmaciver.com, message him as DRMacIver on irc.freenode.net, or for violations on GitHub
that you want to draw his attention to you can also mention him as @DRMacIver.
Other people (especially Hypothesis team members) should feel free to call people on code of conduct violations when they see them,
and it is appreciated but not required (especially if doing so would make you feel uncomfortable or unsafe).
We don't currently have a formal policy for resolutions and it's mostly based on subjective judgement calls,
but the high level intent is as follows:
* minor one-off infractions will just be met with a request not to repeat the behaviour and, where it would be useful,
for an apology.
* Major infractions and repeat offenders will be banned from the community.
If you disagree with David's judgement on any particular event, please feel free to tell him so.
Also, people who have a track record of bad behaviour outside of the Hypothesis community may be banned even
if they obey all these rules if their presence is making people uncomfortable.
hypothesis-hypothesis-python-4.36.2/CONTRIBUTING.rst 0000664 0000000 0000000 00000034564 13541036175 0022203 0 ustar 00root root 0000000 0000000 =============
Contributing
=============
First off: It's great that you want to contribute to Hypothesis! Thanks!
------------------
Ways to Contribute
------------------
Hypothesis is a mature yet active project. This means that there are many
ways in which you can contribute.
For example, it's super useful and highly appreciated if you do any of:
* Submit bug reports
* Submit feature requests
* Write about Hypothesis
* Give a talk about Hypothesis
* Build libraries and tools on top of Hypothesis outside the main repo
* Submit PRs
If you build a Hypothesis strategy that you would like to be more widely known
please add it to the list of external strategies by preparing a PR against
the docs/strategies.rst file.
If you find an error in the documentation, please feel free to submit a PR that
fixes the error. Spot a tyop? Fix it up and send us a PR!
You can read more about how we document Hypothesis in ``guides/documentation.rst``
The process for submitting source code PRs is generally more involved
(don't worry, we'll help you through it), so do read the rest of this document.
If you're planning a larger change, the contributor guides (in the ``guides/``
directory) will make sure you're on the right track.
----------------------------------
Installing from source and testing
----------------------------------
If you want to install directly from the source code (e.g. because you want to
make changes and install the changed version) you can do this with:
.. code:: bash
pip install -r requirements/test.txt
pip install -r requirements/tools.txt
pip install -e hypothesis-python/
# You don't need to run the tests, but here's the command:
pytest hypothesis-python/tests/cover/
You may wish to do all of this in a
`virtualenv `_. For example:
.. code:: bash
virtualenv venv
source venv/bin/activate
pip install hypothesis
Will create an isolated environment where you can install and try out
Hypothesis without affecting your system packages.
-----------------------
Copyright and Licensing
-----------------------
It's important to make sure that you own the rights to the work you are submitting.
If it is done on work time, or you have a particularly onerous contract, make sure
you've checked with your employer.
All work in Hypothesis is licensed under the terms of the
`Mozilla Public License, version 2.0 `_. By
submitting a contribution you are agreeing to licence your work under those
terms.
Finally, if it is not there already, add your name (and a link to your GitHub
and email address if you want) to the list of contributors found at
the end of this document, in alphabetical order. It doesn't have to be your
"real" name (whatever that means), any sort of public identifier
is fine. In particular a GitHub account is sufficient.
-----------------------
The actual contribution
-----------------------
OK, so you want to make a contribution and have sorted out the legalese. What now?
First off: If you're planning on implementing a new feature, talk to us
first! Come `join us on IRC `_,
or open an issue. If it's really small feel free to open a work in progress pull request sketching
out the idea, but it's best to get feedback from the Hypothesis maintainers
before sinking a bunch of work into it.
If you're working on an existing issue, leave a comment so we can try to avoid
duplicating your work before you open a pull request.
In general work-in-progress pull requests are totally welcome if you want early feedback
or help with some of the tricky details. Don't be afraid to ask for help.
In order to get merged, a pull request will have to have a green build (naturally) and
to be approved by a Hypothesis maintainer (and, depending on what it is, possibly specifically
by DRMacIver).
The review process is the same one that all changes to Hypothesis go through, regardless of
whether you're an established maintainer or entirely new to the project. It's very much
intended to be a collaborative one: It's not us telling you what we think is wrong with
your code, it's us working with you to produce something better together.
We have `a lengthy check list `_ of things we look for in a review. Feel
free to have a read of it in advance and go through it yourself if you'd like to. It's not
required, but it might speed up the process.
Once your pull request has a green build and has passed review, it will be merged to
master fairly promptly. This will immediately trigger a release! Don't be scared. If that
breaks things, that's our fault not yours - the whole point of this process is to ensure
that problems get caught before we merge rather than after.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pull request or external package?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New strategies can be added to Hypothesis, or published as an external package
on PyPI - either is fine for most strategies. If in doubt, ask!
It's generally much easier to get things working outside, because there's
more freedom to experiment and fewer requirements in stability and API style.
We're happy to review and help with external packages as well as pull requests;
several parts of Hypothesis started life outside and were integrated later
(with permission, of course). For clarity, we suggest naming your package
in the pattern of ``hypothesis-regex`` and ``hypothesis-protobuf`` on PyPI.
On the other hand, being inside gets you access to some deeper implementation
features (if you need them) and better long-term guarantees about maintenance.
We particularly encourage pull requests for new composable primitives that
make implementing other strategies easier, or for widely used types in the
Python standard library. Strategies for other things are also welcome;
anything with external dependencies just goes in ``hypothesis.extra``.
~~~~~~~~~
The build
~~~~~~~~~
The build is driven by a ``build.sh`` shell script, which delegates to a custom Python-based build system.
Actually running the tests is managed by `tox `_, but the build system
will call out to the relevant tox environments so you mostly don't have to know anything about that
unless you want to make changes to the test config. You also mostly don't need to know anything about the build system
except to type ``./build.sh`` followed by the name of the task you want to run.
All of it will be checked on CI so you don't *have* to run anything locally, but you might
find it useful to do so: A full Travis run takes about twenty minutes, and there's often a queue,
so running a smaller set of tests locally can be helpful.
The build system should be "fairly" portable, but is currently only known to work on Linux or OS X. It *might* work
on a BSD or on Windows with cygwin installed, but it hasn't been tried. If you try it and find it doesn't
work, please do submit patches to fix that.
Some notable commands:
``./build.sh check-coverage`` will verify 100% code coverage by running a
curated subset of the test suite.
``./build.sh check-py36`` (etc.) will run most of the test suite against a
particular python version.
``./build.sh format`` will reformat your code according to the Hypothesis coding style. You should use this before each
commit ideally, but you only really have to use it when you want your code to be ready to merge.
You can also use ``./build.sh check-format``, which will run format and some linting and will then error if you have a
git diff. Note: This will error even if you started with a git diff, so if you've got any uncommitted changes
this will necessarily report an error.
Look in ``.travis.yml`` for a short list of other supported build tasks.
Note: The build requires a lot of different versions of python, so rather than have you install them yourself,
the build system will install them itself in a local directory. This means that the first time you run a task you
may have to wait a while as the build downloads and installs the right version of python for you.
--------------------
List of Contributors
--------------------
The primary author for most of Hypothesis is David R. MacIver (me). However the following
people have also contributed work. As well as my thanks, they also have copyright over
their individual contributions.
* `Adam Johnson `_
* `Adam Sven Johnson `_
* `Alex Gaynor `_
* `Alex Stapleton `_
* `Alex Willmer `_ (alex@moreati.org.uk)
* `Ben Peterson `_ (killthrush@hotmail.com)
* `Benjamin Lee `_ (benjamindlee@me.com)
* `Bex Dunn `_ (bex.dunn@gmail.com)
* `Bill Tucker `_ (imbilltucker@gmail.com)
* `Buck Evan, copyright Google LLC `_
* `Cameron McGill `_
* `Charles O'Farrell `_
* `Charlie Tanksley `_
* `Chase Garner `_ (chase@garner.red)
* `Chris Down `_
* `Christopher Martin `_ (ch.martin@gmail.com)
* `Conrad Ho `_ (conrad.alwin.ho@gmail.com)
* `Cory Benfield `_
* `Cristi Cobzarenco `_ (cristi@reinfer.io)
* `Damon Francisco `_ (damontfrancisco@yahoo.com)
* `Daniel J. West `_
* `David Bonner `_ (dbonner@gmail.com)
* `David Chudzicki `_ (dchudz@gmail.com)
* `Derek Gustafson `_
* `Dion Misic `_ (dion.misic@gmail.com)
* `Eduardo Enriquez `_ (eduardo.a.enriquez@gmail.com)
* `El Awbery `_
* `Emmanuel Leblond `_
* `Felix Grünewald `_
* `Florian Bruhin `_
* `follower `_
* `Gary Donovan `_
* `Graham Williamson `_
* `Grant David Bachman `_ (grantbachman@gmail.com)
* `Gregory Petrosyan `_
* `Grigorios Giannakopoulos `_
* `Jack Massey `_
* `Jakub Nabaglo `_ (j@nab.gl)
* `Jenny Rouleau `_
* `Jeremy Thurgood `_
* `J.J. Green `_
* `JP Viljoen `_ (froztbyte@froztbyte.net)
* `Jochen Müller `_
* `Joey Tuong `_
* `Jonathan Gayvallet `_ (jonathan.gayvallet@orange.com)
* `Jonty Wareing `_ (jonty@jonty.co.uk)
* `Joshua Boone `_ (joshuaboone4190@gmail.com)
* `jmhsi `_
* `jwg4 `_
* `Kai Chen `_ (kaichen120@gmail.com)
* `Karthikeyan Singaravelan `_ (tir.karthi@gmail.com)
* `Katrina Durance `_
* `kbara `_
* `Kristian Glass `_
* `Kyle Reeve `_ (krzw92@gmail.com)
* `Lee Begg `_
* `Lisa Goeller `_
* `Louis Taylor `_
* `Luke Barone-Adesi `_
* `Lundy Bernard `_
* `Marco Sirabella `_
* `marekventur `_
* `Marius Gedminas `_ (marius@gedmin.as)
* `Markus Unterwaditzer `_ (markus@unterwaditzer.net)
* `Mathieu Paturel `_ (mathieu.paturel@gmail.com)
* `Matt Bachmann `_ (bachmann.matt@gmail.com)
* `Max Nordlund `_ (max.nordlund@gmail.com)
* `Maxim Kulkin `_ (maxim.kulkin@gmail.com)
* `mulkieran `_
* `Nicholas Chammas `_
* `Paul Ganssle `_ (paul@ganssle.io)
* `Paul Lorett Amazona `_
* `Paul Stiverson `_
* `Peadar Coyle `_ (peadarcoyle@gmail.com)
* `Pierre-Jean Campigotto `_
* `Richard Boulton `_ (richard@tartarus.org)
* `Ryan Soklaski `_ (rsoklaski@gmail.com)
* `Ryan Turner `_ (ryan.turner@uber.com)
* `Sam Bishop (TechDragon) `_ (sam@techdragon.io)
* `Sam Hames `_
* `Sanyam Khurana `_
* `Saul Shanabrook `_ (s.shanabrook@gmail.com)
* `Stuart Cook `_
* `SuperStormer `_
* `Sushobhit `_ (sushobhitsolanki@gmail.com)
* `Tariq Khokhar `_ (tariq@khokhar.net)
* `Tessa Bradbury `_
* `Thomas Grainge `_
* `Tim Martin `_ (tim@asymptotic.co.uk)
* `Thomas Kluyver `_ (thomas@kluyver.me.uk)
* `Tom McDermott `_ (sponster@gmail.com)
* `Tyler Gibbons `_ (tyler.gibbons@flexport.com)
* `Tyler Nickerson `_
* `Vidya Rani `_ (vidyarani.d.g@gmail.com)
* `Will Hall `_ (wrsh07@gmail.com)
* `Will Thompson `_ (will@willthompson.co.uk)
* `Wilfred Hughes `_
* `Zac Hatfield-Dodds `_ (zac.hatfield.dodds@gmail.com)
* `Zebulun Arendsee `_ (zbwrnz@gmail.com)
hypothesis-hypothesis-python-4.36.2/LICENSE.txt 0000664 0000000 0000000 00000000636 13541036175 0021356 0 ustar 00root root 0000000 0000000 Copyright (c) 2013, David R. MacIver
All code in this repository except where explicitly noted otherwise is released
under the Mozilla Public License v 2.0. You can obtain a copy at https://mozilla.org/MPL/2.0/.
Some code in this repository comes from other projects. Where applicable, the
original copyright and license are noted and any modifications made are released
dual licensed with the original license.
hypothesis-hypothesis-python-4.36.2/Makefile 0000664 0000000 0000000 00000000362 13541036175 0021167 0 ustar 00root root 0000000 0000000 # You don't need to use this Makefile and should use build.sh instead. This is
# just here so that us poor souls who remember the Make based system and keep
# typing "make target" can ease our transition to the new system.
%:
./build.sh $@
hypothesis-hypothesis-python-4.36.2/README.rst 0000664 0000000 0000000 00000003214 13541036175 0021215 0 ustar 00root root 0000000 0000000 ==========
Hypothesis
==========
Hypothesis is family of testing libraries which let you write tests parametrized
by a source of examples. A Hypothesis implementation then generates simple and
comprehensible examples that make your tests fail.
This simplifies writing your tests and makes them more powerful at the same time,
by letting software automate the boring bits and do them to a higher standard than a human would,
freeing you to focus on the higher level test logic.
This sort of testing is often called "property-based testing",
and the most widely known implementation of the concept is the Haskell
library `QuickCheck `_,
but Hypothesis differs significantly from QuickCheck and is designed to fit
idiomatically and easily into existing styles of testing that you are used to,
with absolutely no familiarity with Haskell or functional programming needed.
The currently available implementations of Hypothesis are:
* `Hypothesis for Python `_ is the original implementation,
and the only one that is currently fully production ready.
* `Hypothesis for Ruby `_
is an ongoing project that we intend to eventually reach parity with
Hypothesis for Python.
* `Hypothesis for Java `_
is a prototype written some time ago. It's far from feature complete and is
not under active development, but was intended to prove the viability of the
concept.
This repository will eventually house all implementations of Hypothesis, but
we are currently in the process of consolidating the existing repositories into a single one.
hypothesis-hypothesis-python-4.36.2/azure-pipelines.yml 0000664 0000000 0000000 00000007420 13541036175 0023370 0 ustar 00root root 0000000 0000000 # Schema docs at https://aka.ms/yaml
trigger:
- master
jobs:
- job: linux
pool:
vmImage: 'Ubuntu 16.04'
strategy:
matrix:
check-whole-repo-tests:
TASK: check-whole-repo-tests
lint:
TASK: lint
lint-ruby:
TASK: lint-ruby
check-format:
TASK: check-format
check-rust-tests:
TASK: check-rust-tests
check-coverage:
TASK: check-coverage
check-pypy:
TASK: check-pypy
check-pypy3:
TASK: check-pypy3
check-py36:
TASK: check-py36
check-py27:
TASK: check-py27
check-py35:
TASK: check-py35
check-py37:
TASK: check-py37
check-quality:
TASK: check-quality
check-ruby-tests:
TASK: check-ruby-tests
check-unicode:
TASK: check-unicode
check-py27-typing:
TASK: check-py27-typing
check-nose:
TASK: check-nose
check-pytest30:
TASK: check-pytest30
check-django22:
TASK: check-django22
check-django21:
TASK: check-django21
check-django20:
TASK: check-django20
check-django111:
TASK: check-django111
check-pandas19:
TASK: check-pandas19
check-pandas22:
TASK: check-pandas22
check-pandas23:
TASK: check-pandas23
check-pandas24:
TASK: check-pandas24
check-pandas25:
TASK: check-pandas25
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.6'
- script: sudo apt-get update && sudo apt-get install libreadline-dev libsqlite3-dev shellcheck
displayName: Install apt dependencies
- script: ./build.sh check-installed
displayName: Install Python
- script: ./build.sh
displayName: Run tests
- job: windows
pool:
vmImage: 'windows-2019'
strategy:
matrix:
check-py36-x64:
python.version: '3.6'
python.architecture: 'x64'
check-py36-x86:
python.version: '3.6'
python.architecture: 'x86'
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '$(python.version)'
architecture: '$(python.architecture)'
- script: |
pip install --upgrade setuptools pip wheel
pip install setuptools -r requirements/test.txt
pip install hypothesis-python/[all]
displayName: Install dependencies
- script: |
cd hypothesis-python
pytest
displayName: Run tests
- job: windows_py2
pool:
vmImage: 'windows-2019'
strategy:
matrix:
check-py27-x64:
python.version: '2.7'
python.architecture: 'x64'
check-py27-x86:
python.version: '2.7'
python.architecture: 'x86'
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '$(python.version)'
architecture: '$(python.architecture)'
- script: |
pip install --upgrade setuptools pip wheel
pip install setuptools -r requirements/py2.txt
pip install hypothesis-python/[all]
displayName: Install dependencies
- script: |
cd hypothesis-python
pytest
displayName: Run tests
- job: osx
pool:
vmImage: 'macOS-10.13'
strategy:
matrix:
check-py27:
TASK: check-py27
check-py36:
TASK: check-py36
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.6'
- script: |
brew update
brew install readline xz ncurses
./build.sh install-core
displayName: Install dependencies
- script: ./build.sh
displayName: Run tests
# TODO: Deploy jobs dependent on above
hypothesis-hypothesis-python-4.36.2/brand/ 0000775 0000000 0000000 00000000000 13541036175 0020614 5 ustar 00root root 0000000 0000000 hypothesis-hypothesis-python-4.36.2/brand/README.rst 0000664 0000000 0000000 00000003743 13541036175 0022312 0 ustar 00root root 0000000 0000000 Logos and other pretty things
=============================
Hypothesis has a beautiful logo, thanks to the generous work of Libby Berrie
in `issue #1519 `__.
General guidelines:
- Prefer vector (``.svg``) formats to raster formats (``.png``) wherever possible.
- We consider the rainbow version to be canonical. The blue variant is provided
for cases such as monochome versions or printing with a limited palette.
With that in mind, you are welcome to use these logos to refer to Hypothesis -
and if you're not sure whether a specific use is OK, please get in touch and ask!
For example, we often bring Hypothesis stickers to conferences but can't make
it to everything. If you want to print your own Hypothesis stickers, upload
the image to `StickerMule `__
and pick one of the vinyl options - that's how we get ours!
Colour palette in GIMP format
#############################
A `colour palette in GIMP format `__ (``.gpl``) is also provided
with the intent of making it easier to produce graphics and documents which
re-use the colours in the Hypothesis Dragonfly logo by Libby Berrie.
The ``hypothesis.gpl`` file should be copied or imported to the appropriate
location on your filesystem. For example:
- ``/usr/share/inkscape/palettes/`` for Inkscape on Ubuntu 18.08
- Edit -> Colors -> Import... then select the ``hypothesis.gpl`` file in Scribus
on Ubuntu 18.08
- Windows -> Dockable Dialogs -> Palettes -> Palettes Menu -> Add Palette ->
Import from file... then select the ``hypothesis.gpl`` file in GIMP on Ubuntu
18.08
Once imported, the colour palette is then available for easy manipulation of
colours within the user interface.
Inkscape:
.. image:: inkscape.png
:width: 800px
:align: left
:alt: Inkscape showing Hypothesis colour palette
GIMP:
.. image:: gimp.png
:width: 800px
:align: left
:alt: GIMP showing Hypothesis colour palette
hypothesis-hypothesis-python-4.36.2/brand/dragonfly-blue.svg 0000664 0000000 0000000 00000044025 13541036175 0024254 0 ustar 00root root 0000000 0000000