summaryrefslogtreecommitdiff
path: root/requirements-prod.txt
Commit message (Collapse)AuthorAge
* Add support for Django 2.0Stephen Finucane2018-08-26
| | | | | | | | | | | | | | | | | | | | | | | | Nothing too complicated here except for the addition of a new compat wrapper, which will be removed again shortly. According to the Django release notes, Django should function with Python 3.4. However, it was not possible to get this functioning due to the below error: Traceback (most recent call last): File ".../patchwork/manage.py", line 11, in <module> ... File ".../django/db/models/fields/related.py", line 313, in contribute_to_class 'app_label': cls._meta.app_label.lower(), TypeError: unsupported operand type(s) for %: 'bytes' and 'dict' This does not appear to be an issue with Patchwork but the exact root cause has not been identified. As a result, only Python 3.5 and 3.6 are marked as supported for this Django version. As this is the first Python 3-only dependency we have, we need to start making use of the 'python_version' environment marker. Signed-off-by: Stephen Finucane <stephen@that.guru> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Remove support for Django 1.8, 1.9, 1.10Stephen Finucane2018-08-26
| | | | | | | | | | | | | | These are now all EOL and Debian Testing supports Django 1.11 (LTS). We can and should drop them. This change does not remove the many compat wrappers. These will be removed separately (there are a lot of them). This leaves 1.11 as the only supported version. This will be remedied shortly with the inclusion of Django 2.0 support. Signed-off-by: Stephen Finucane <stephen@that.guru> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Add support for django-filter 1.1Stephen Finucane2018-08-26
| | | | | | | There's one warning to handle here. Signed-off-by: Stephen Finucane <stephen@that.guru> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Add support for Django REST Framework 3.7, 3.8Stephen Finucane2018-08-26
| | | | | | | | No breaking changes that concern us here. Signed-off-by: Stephen Finucane <stephen@that.guru> Reviewed-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Update sqlparse from 0.2.3 to 0.2.4pyup-bot2018-04-25
|
* requirements: Enable Django 1.11Stephen Finucane2017-12-03
| | | | | | | This is now completely supported. Let's enable it. Signed-off-by: Stephen Finucane <stephen@that.guru> Tested-by: Daniel Axtens <dja@axtens.net>
* Update djangorestframework from 3.5 to 3.6pyup-bot2017-04-14
|
* Update psycopg2 from 2.7 to 2.7.xpyup-bot2017-03-13
|
* Update sqlparse from 0.2.2 to 0.2.3pyup-bot2017-03-04
|
* Pin psycopg2 to latest version 2.7pyup-bot2017-03-01
|
* REST: Integrate django-filter supportStephen Finucane2017-01-22
| | | | | | | | This mostly works out of the box, thanks to Django REST Framework. Mostly unique fields, like name or email, are excluded as these will be handled separately. Signed-off-by: Stephen Finucane <stephen@that.guru>
* Pin sqlparse to latest version 0.2.2pyup-bot2017-01-04
|
* REST: Use generic views instead of ViewSetsStephen Finucane2016-12-23
| | | | | | | | | | | | | | | | | | | | ViewSet provide an easy way to define an API, but they don't offer much flexibility. To get them to work as expected, a lot of hacks were required. Generic views provide a more verbose, but ultimately easier to understand, version. Using generic views lets us remove the dependency of drf-nested-routers, bringing us back down to two main dependencies. It also lets us remove the AuthenticatedReadOnly permission class, as the DRF provides a similar permission class that can be used with generic views. The main user facing change is that invalid methods, such as POST on an endpoint that doesn't allow object creation, will now return a HTTP 405 (Method Not Allowed) error code rather than the HTTP 403 (Forbidden) error code previously returned. This is the semantically correct option and should have been used all along. Signed-off-by: Stephen Finucane <stephen@that.guru> Reviewed-by: Daniel Axtens <dja@axtens.net>
* requirements: Test older versions of DRFStephen Finucane2016-11-18
| | | | | | | | We still care about Django 1.6 and 1.7, at least until 2.0 is released. Start testing REST functionality on these versions by using older versions. Signed-off-by: Stephen Finucane <stephen@that.guru>
* requirements: Loosen requirements for RDBMS libsStephen Finucane2016-11-18
| | | | Signed-off-by: Stephen Finucane <stephen@that.guru>
* requirements: Add support for Django 1.10Stephen Finucane2016-10-10
| | | | | | | | All issues around 1.10 support have been resolved. Add tox targets and extend the range of supported versions to include this release. Signed-off-by: Stephen Finucane <stephen@that.guru> Reviewed-by: Daniel Axtens <dja@axtens.net>
* Add sqlparse to production requirementsDaniel Axtens2016-09-25
| | | | | | | | | It's required for migration #10 (w/ RunSQL), per upstream docs: https://docs.djangoproject.com/en/1.8/ref/migration-operations/#runsql Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Stephen Finucane <stephenfinucane@hotmail.com>
* requirements: Use any supported Django versionStephen Finucane2016-03-25
| | | | | | | | | | Patchwork now supports Django 1.9. It continues to support Django 1.8, 1.7 and 1.6, though the latter two are not supported upstream and are therefore not recommended. Update development requirements to reflect this. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com> Reviewed-by: Andy Doan <andy.doan@linaro.org>
* requirements: Use PostgreSQL in productionStephen Finucane2016-02-08
| | | | | | | | The example "production" settings expect a PostgreSQL database backend, yet the requirements file for the same scenario install MySQL dependencies. Correct this mismatch. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* Cleanup requirementsStephen Finucane2015-11-21
| | | | | | | | | | | * python-dateutil is only used in tests, so remove it from the production requirements * mysqlclient is prefered to MySQLdb, so use that [1] * selenium does not have its version fixed, so resolve that [1] https://docs.djangoproject.com/en/1.8/ref/databases/#mysql-db-api-drivers Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* Add requirements-test.txtStephen Finucane2015-11-21
| | | | | | | | | | | | | | It's annoying that Django is not installed by default when setting up a development environment. This is currently necessary because tox uses these requirements files and it needs to test against multiple versions of Django. Resolve this issue by adding a 'requirements-test' file, thus allowing for Django-ful and Django-less scenarios. This also allows us to delete 'requirements-base', which was a good idea but alas contained too few options to really be viable. A little duplication is better here. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
* Move requirements into base directoryStephen Finucane2015-11-21
These are documentation and therefore don't belong in the documentation directory. The base directory is the usual location for these files, so move them there. Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>