* Use Python 3.10 for deployments on PyPi
* Update gh-action-pypi-publish version
* Update python version
* Update checkout and setup-python versions
* Upgrade dev dependencies
* fromat examples and few files to follow black new version
* Upgrade pytest version
---------
Co-authored-by: Firas Kafri <firaskafri@Firass-MacBook-Pro-2.local>
* 🔧 Add pre-commit config
Similar to graphene and graphene-sqlalchemy
* ⬆ Bump black
* 👷 Lint on CI
* ⬆ Bump flake8-black
* 🔧 Keep excluding migrations
* ⬆ Bump flake8
* 🔧 Remove black and flake8 from tox config
* ⬆ Update pre-commit versions
* Upgrade syntax to python 3.7+
* Format with pre-commit
dedent docs/schema.py to allow formatting
* Fix tests on python 3.7
* merge master into v3
* fix order_by snake casing by checking if value is None, switch executor to execution_context_class since schema.execute no longer supports executor
* fix linting by removing duplicate defintion and test of convert_form_field_to_string_list
* use `to_represenation` in favor of `get_attribute`
* fix datetime type does get converted to a string
to_representation will convert the datetime field into a string representation. However the to_representation on the method field will only call its underlying method.
* fix add missing import
* apply black formatter
* add test for serializer method field
* apply black format
* improve backward compatibility
by using date's class contructor instead of fromisostring
* apply black format
* fix black format issue
* Include setup.py in black formatting
* Add new flake8 plugins and update errors to look for
* Fix duplicate test name
* Don't use mutable data structure
* Install all dev dependencies for flake8 and black tox envs
Upon success the result was correct but also included:
"errors": [
{
"message": "User Error: expected iterable, but did not find one
for field <SerializerMutation_Subclass>Payload.errors."
}
]
This seemed to be due to Payload.errors defaulting to graphene.List
rather than unset or None. Unsure what exactly changed with 2.x to break
this, so I welcome a better fix, but explicitly setting errors to None
also seems easy enough.