| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
'~= 2.2' will match '2.2.N', '2.3.N', etc. but not '3.0.N'. What we want
in most cases is to match '2.2.N' only. Ensure this is the case.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: c90473ea ("requirements: Switch to compatible releases")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit ab0c443691, we switched from using commit ranges to fixed
ranges. This was a good idea in so far as it ensures we're providing an
application with dependencies that are guaranteed to work. However,
Patchwork as a project isn't active enough to warrant the continued busy
work effort necessary to keep bumping these versions and it's probably
about time to abandon the experiment. However, rather than switching
back to version ranges, use the compatible releases feature introduced
in PEP 440 [1]. This gives us most of the benefits of ranges but with a
nicer syntax.
[1] https://www.python.org/dev/peps/pep-0440/#compatible-release
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add validation using the rather excellent 'openapi_core' library. The
biggest issue we have to contend with is the fact that 'openapi_core'
expects us to be able to provide a templated URL string for each request
(e.g. '/api/patches/123/' would become '/api/patches/<id>/') and Django
doesn't provide a way to do this [*]. We work around this by
reverse-engineering some of the Django code to turn a URL to its
matching regex, which we can then easily convert into a template string.
It's kind of hacky and not at all portable but, crucially, it does work
and has highlighted some nice bugs in the API that have already merged.
Going forward, we can probably modify 'openapi_core' somewhat to remove
the need for the templated URL string. If and when this happens, most of
the funkier code here can happily go away.
[*] Django 2.0+ [1] does actually provide a way to do template
string-based URLs and in fact recommends them now, with regexes being
reserved for more advanced corner cases. However, we don't want to drop
support for the Django 1.11 yet as it is the most recent LTS release.
[1] https://docs.djangoproject.com/en/2.1/ref/urls/#django.urls.path
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was previously installed as part of 'django-debug-toolbar' [1] but
as this dependency is no longer installed for tests, the dependency is
now missing. Fix this by manually specifying it.
[1] https://github.com/jazzband/django-debug-toolbar/blob/1.10.1/setup.py#L20-L23
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: a7454712 ("Remove django-debug-toolbar from test requirements")
|
|
|
|
|
|
|
| |
This should speed up tests slightly and remove an unnecessary
dependency.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
| |
Use the latest and greatest.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given that 'tox' doesn't actually read any of these, there's no reason
to use ranges of requirements. Instead, use the latest and greatest for
live instances and rely on tox to validate behavior with older versions.
The selenium dependency, which is no longer required since commit
bab2895f, is removed. The psycopg2 dependency is updated to use
psycopg2-binary, as this avoids the need for the libpg library and
removes a deprecation warning.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Daniel Axtens <dja@axtens.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This resolves a deprecation warning that's recently been raised:
UserWarning: The psycopg2 wheel package will be renamed from release
2.8; in order to keep installing from binary please use "pip install
psycopg2-binary" instead. For details see:
<http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to easily test against PostgreSQL using the same
tooling we normally use. This is helpful in (for example) shaking
out the test failures that were observed on ozlabs.org
To use it:
docker-compose -f docker-compose-pg.yml <usual argument>
(You may find in necessary to do a 'docker-compose down' first,
depending on what state the system is in and what command you're
running.)
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
| |
Reviewed-by: Stephen Finucane <stephen@that.guru>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This partially reverts commit febad055fb6609369f1a465a5eec323549c5c065.
While Django REST Framework works with Django 1.6 and 1.7, the versions
of Django Filters that provide DRF integration do not [1]. It doesn't
really make sense to enable only partial REST API support (i.e. no
filtering) for users with older Django versions and this approach will
cause far too much confusion among users. Better to just drop REST API
support for users with these insecure versions and encourage them to
update to supported versions of Django should they wish to use these
features.
[1] https://github.com/carltongibson/django-filter/blob/0.15.0/CHANGES.rst
Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: 0fc32337 ("REST: Integrate django-filter support")
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
This requires explicitly declaring the 'field' parameter.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
| |
3.0 introduces no notable changes for our use cases. Use the latest and
greatest.
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
|
| |
1.6 introduces little to no changes [1]. We already use the explicit
setup, so simply switch to the latest and greatest version.
[1] https://django-debug-toolbar.readthedocs.io/en/1.6/changes.html
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
| |
Signed-off-by: Stephen Finucane <stephen@that.guru>
|
|
|
|
|
|
|
|
| |
This version is compatible with all versions of Django that Patchwork
is recommended for.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Reviewed-by: Daniel Axtens <dja@axtens.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the latest version. This breaks compatibility with Django 1.7,
but this version is unsupported and should not be used for development.
We do, however, continue to test support for Django 1.7 and 1.6.
This also prevents the need to manually track sqlparse dependency [1].
[1] https://github.com/jazzband/django-debug-toolbar/issues/856
Signed-off-by: Stephen Finucane <stephenfinucane@hotmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exports patch checks via the REST API.
The drf-nested-routers package is used to handle the fact Checks are
nested under a Patch.
Security Constraints:
* Anyone (logged in or not) can read all objects.
* No one can update/delete objects.
* Project maintainers and patch owners may create objects.
Signed-off-by: Andy Doan <andy.doan@linaro.org>
Reviewed-by: Stephen Finucane <stephen.finucane@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the ability to expose a REST API based on the Django REST
framework project. Since this project isn't packaged in most current
distributions, we ensure that its both installed and enabled before
trying to use it.
Signed-off-by: Andy Doan <andy.doan@linaro.org>
Inspired-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Stephen Finucane <stephen.finucane@intel.com>
|
|
|
|
|
|
|
|
| |
There's not really any reason to pin the requirements for dependencies
only used in tests, so don't do it. Replace these specific versions
with broader, major-version checks.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This tool is exceptionally helpful for debugging issues with Django:
install it as part of the 'dev' configuration. This only works on
Django > 1.6, due to a lack of support for older versions in the
upstream.
A note is included to help users avoid the issues seen when running
patchwork on a different machine.
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It would be good to provide the required packages for devs using both
MySQL and PostgreSQL. However, there does not appear to be any way to
specify an exclusive-or condition in pip requirements files and the
existing behavior of including dependencies for both RDBMSs means
system packages have to be installed for both, when you are likely
only using one. This is particularly problematic when you want to
set up a fast dev environment using something like Vagrant.
Settle on MySQL for now, until such a time as the consensus is to go
all-in with PostgreSQL (including docs, for example).
Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>
|
|
|
|
|
|
|
| |
The version of dateutil currently used does not support Python3, so
instead use the latest version.
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are a number of environment variables that users can set to
configure different aspects of their testing environment. Rework these
like so:
* People use PostgreSQL, so make it as easy as possible for them to
develop and test against it. Add a 'PW_TEST_DB_TYPE' setting
* Attempt to use defaults for the username and password in settings
* Allow the user to configure the database name, if they so wish
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>
|