| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
There's one warning to handle here.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
| |
This is now completely supported. Let's enable it.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Tested-by: Daniel Axtens <dja@axtens.net>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
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>
|