This is a follow up for c8d8973c7e
(dropping Python 3.5). There waere some leftovers in requirements for
Pythonv versions `connexion` no longer supports.
* setup.py: Support jsonschema >= 3.0.0
Other projects have started using jsonschema >= 3.0.0, and modern python
packaging tools such as poetry now fail to install projects using both
connexion and a different dependency if they depend on different
versions of jsonschema.
Allow jsonschema versions >= 3.0.0 to avoid this problem.
See: https://github.com/sdispater/poetry/issues/697
* Avoid warning when using jsonschema >= 3.0
jsonschema 3.0.0 changed the API to deprecate the types parameter of the
jsonschema.IValidator constructor and now raises a warning when using
it.
Avoid the warning by checking the jsonschema version and switching to
the new way to implement this when it is >= 3.0. Note that while
jsonschema 2.x did have jsonschema.validators.extend, it did not support
the type_checker argument, so the same code cannot be used with
jsonschema 2.x.
* Revert "set max aiohttp version to 3.5.1 (until build is fixed) (#844)"
This reverts commit b2a4287405.
* Fix test_run_with_aiohttp_not_installed
Somewhere between 3.5.1 and 3.5.2, the aiohttp reimport started
succeeding (in connexion.connexion.cli.run()). It's not clear which
change caused the issue, but it's probably one of:
- aio-libs/aiohttp#3469 (Remove wildcard imports)
- aio-libs/aiohttp#3464 (Don't suppress gunicorn cleanup errors)
- aio-libs/aiohttp#3471 (Refactor workers)
- aio-libs/aiohttp#3500 (Ignore done tasks)
In any case, setting sys.modules['aiohttp'] = None should prevent
reimporting it. See: https://stackoverflow.com/a/1350574
I successfully tested locally on py37 with aiohttp 3.5.1 and 3.5.2.
* Bump flask to be at least 1.0.4
Reasons:
- `flask==0.10.1` was released in 2013, which makes it quite old thus unsupported.
- On Flask webpage you can find an information pointing to `1.x` branch as latest stable
- different tools, including these used in `connexion` progressed leaving Python versions, for which `flask<1.0` has been developed.
* match instead of message
- App and Api options must be provided through the "options" argument (``old_style_options`` have been removed).
- You must specify a form content-type in 'consumes' in order to consume form data.
- The `Operation` interface has been formalized in the `AbstractOperation` class.
- The `Operation` class has been renamed to `Swagger2Operation`.
- Array parameter deserialization now follows the Swagger 2.0 spec more closely.
In situations when a query parameter is passed multiple times, and the collectionFormat is either csv or pipes, the right-most value will be used.
For example, `?q=1,2,3&q=4,5,6` will result in `q = [4, 5, 6]`.
The old behavior is available by setting the collectionFormat to `multi`, or by importing `decorators.uri_parsing.AlwaysMultiURIParser` and passing `parser_class=AlwaysMultiURIParser` to your Api.
- The spec validator library has changed from `swagger-spec-validator` to `openapi-spec-validator`.
- Errors that previously raised `SwaggerValidationError` now raise the `InvalidSpecification` exception.
All spec validation errors should be wrapped with `InvalidSpecification`.
- Support for nullable/x-nullable, readOnly and writeOnly/x-writeOnly has been added to the standard json schema validator.
- Custom validators can now be specified on api level (instead of app level).
- Added support for basic authentication and apikey authentication
- If unsupported security requirements are defined or ``x-tokenInfoFunc``/``x-tokenInfoUrl`` is missing, connexion now denies requests instead of allowing access without security-check.
- Accessing ``connexion.request.user`` / ``flask.request.user`` is no longer supported, use ``connexion.context['user']`` instead
- Created a metaclass for AbstractAPI (it is used to set the jsonifier for the class);
- Created a new class method AbstractAPI._set_jsonifier;
- Changed the code to use the new jsonifier interface;
- Create a new module called coroutines_wrapper to put the wrapper functions with the 'yield from' statement. It is used to enable frameworks with coroutine handlers;
- Did the AioHttpApi.get_request coroutine and add req.read() to get the request body;
- Moved the flask jsonifier to utils and did it a generic jsonifier;
- Created a function called 'has_coroutine' on utils module;
- Added aiohttp_jinja2 to requirements-aiohttp;
- Added a new python3 coreragerc file to skip only python2 lines;
- Fixed the set of validation_response on test_aiohttp_simple_api.py;
- Added the test to check the aiohttp body request;
- Fixed the response for 'aiohttp_bytes_response' and 'aiohttp_non_str_non_json_response' paths on aiohttp/swagger_simple.yml file.
- Added the AioHttpApi and AioHttpApp on connexion __init__;
- Created an abstract method on AbstractApi to cast the framework response to connexion response;
- Implemented the get_connexion_response on FlaskApi;
- Changed the CLI to use any kind of App class;
- Changed the ResponseValidator to always convert the response to a connexion response;
- Changed the ResponseValidator to support coroutine responses;
- Added the aiohttp as optional dependency;
- Added ujson as optional dependency;
- Skipped the aiohttp tests run on python 2.7;
- Changed the tests configs to run aiohttp tests properly on python 3.4+.
* FIX a typo causing an ERROR log
A small bug was introduced in #500 when sanitizing the request query
parameters. Instead of fetching the arguments from `request.query`,
the parameters were sanitized from the `request.form`. This causes an
error log to be printed, as the parameters are not expected for the
query (for example in the case of a POST request).
Fixes#504
* adds a fixture for testing query param sanitazion
Adds a simple fixture to test form and query parameter sanitazion. This
is mostly related to #522, in which the `formData` parameters were
treated as query parameters.
* add a test to validate form data params
* introduce testfixtures library
* setup.py: Use env markers for Python version-specific dependencies
Changing package properties dynamically in setup.py means that universal
wheels will actually be built only for the builder's environment, and
might not work properly on different platforms/PYthon versions.
Closes https://github.com/zalando/connexion/issues/493
* travis: Upgrade setuptools before running tests
* reqs: Stop installing pathlib from mercurial in dev mode
The mercurial repo is at 0.8 while the latest release on PyPI is 1.0.1
* Order classes by relevance in module
* Order definitions by relevance within module
* Swagger UI options extracted
* New style options
* Use new-style options
* Reuse code
* Sort imports
* Ignore typing imports
* Warn users about parameter name change
* Add back isort check
* Fix isort check
* Example with Flask support
* Only show import error when trying to use Flask
* Re-organize imports
* Move flask_utils next to related module
* Code style
* Change back to incentivizes
* Includes Flask by default
* Project clean up
* Update Rafael Caricio's e-mail address
* Fix conflicts
In order to validate date-time or uri formats jsonschema requires
strict-rfc3339 and rfc3987 to be installed, both of which are licensed
under the GPLv3. To avoid license ambiguity, it makes sense to not
depend on either of them for installation or testing of connexion.
Requirements Builder provides a way to run tests against all interesting
versions of the requirements: minimal, latest as well as development
(from git, hg, svn).
It requires to move the requirements into the setup.py and to provide a
minimal version. requirements-devel aims at helping you working
* It detected a conflict with six version which had to be bumped up;
* building PyYAML from Subversion fails so it's commented in the
requirement-devel.txt file.
A cool blog post on how to keep some balance between setup.py and
requirements.txt file:
https://caremad.io/posts/2013/07/setup-vs-requirement/
trying to run test code in dependencies installed in the project
directory via `virtualenv`.
- `README.rst` is in utf-8 encoding; reading it fails on py34
