New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix tests for django-filter 1.0.0 #122
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,5 +2,5 @@ psycopg2 | |
djangorestframework>=3.3 | ||
coverage==3.7.1 # rq.filter: >=3,<4 | ||
coveralls | ||
django-filter>=0.15,<1.0 | ||
django-filter | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. with experience I've learnt that restricting the versions in use is good, especially when the dependencies introduce backward incompatible changes. Therefore I would put There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's good to be notified in case of issues with new upstream versions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. immagine the case in which we receive a bug free pull request and the build fails because of a new incompatible version of django-filter: that's annoying, because the pull request works and can be merged but the CI build would fail. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I know.. but it helps with being notified. As for pytest-django we also test against Django master, but that job is allowed to fail: when there are several jobs you can see what the cause of the failure is more easily. |
||
contexttimer |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -132,10 +132,12 @@ class GeojsonLocationNoIdDetails(generics.RetrieveUpdateDestroyAPIView): | |
|
||
|
||
class LocationFilter(GeoFilterSet): | ||
contains_properly = GeometryFilter(name='geometry', lookup_type='contains_properly') | ||
contains_properly = GeometryFilter(name='geometry', | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are you sure removing There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is only for the test. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right |
||
lookup_expr='contains_properly') | ||
|
||
class Meta: | ||
model = Location | ||
fields = ['contains_properly'] | ||
|
||
class GeojsonLocationContainedInGeometry(generics.ListAPIView): | ||
queryset = Location.objects.all() | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would leave something like: "this feature has been tested up to django-filter 1.0".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not mention that explicitly: it needs updating later etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The library (documentation, tests, changelog) needs to be updated anyway at each release. If django-filter becomes stable and won't introduce backward incompatible changes I wouldn't mind deleting the note, but this dependency has caused quite a few issues recently and I prefer to do it this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh.. the reason for 1.0.0 is exactly to become stable - all the deprecations have been dropped.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right, in theory. Let's see if it also translates into practice.