Fix Django rest framework issues for mkdocstrings pages in vast_pipeline

[ajstewart]

Currently the following files are skipped in the mkdocstrings generation because of an no attribute error:

vast_pipeline/serializers.py
vast_pipeline/views.py

vast-pipeline/docs/gen_doc_stubs.py

Lines 10 to 14 in 18178eb

	# Problem files because of Django and mkdocs
	# See https://github.com/mkdocstrings/mkdocstrings/issues/141
	# __init__ is there just to avoid building these.
	# TODO: Fix Django pages for mkdocs.
	problem_files = ['serializers.py', 'views.py', '__init__.py']

I believe the same issue as described in mkdocstrings/mkdocstrings#141.

[ajstewart]

This may be fixed by the next release of pytkdocs (> 0.11.1).

[ajstewart]

I revisited this as pytkdocs v0.12.0 was released that included support for Django models (though basic support is noted in the issues).

It seems that this actually regresses the documentation as with the update other files begin to fail with errors such as:

ERROR    -  mkdocstrings.extension: 'GenericForeignKey' object has no attribute 'null'
            Traceback (most recent call last):
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/cli.py", line 205, in main
                output = json.dumps(process_json(line))
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/cli.py", line 114, in
            process_json
                return process_config(json.loads(json_input))
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/cli.py", line 91, in
            process_config
                obj = loader.get_object_documentation(path, members)
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/loader.py", line 358, in
            get_object_documentation
                root_object = self.get_module_documentation(leaf, members)
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/loader.py", line 426, in
            get_module_documentation
                root_object.add_child(self.get_class_documentation(child_node))
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/loader.py", line 506, in
            get_class_documentation
                child = self.get_class_documentation(child_node)
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/loader.py", line 506, in
            get_class_documentation
                child = self.get_class_documentation(child_node)
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/loader.py", line 538, in
            get_class_documentation
                add_method,
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/loader.py", line 599, in
            add_fields
                root_object.add_child(add_method(child_node))
              File "/Users/adam/anaconda3/envs/vast-pipeline-dev/lib/python3.7/site-packages/pytkdocs/loader.py", line 726, in
            get_django_field_documentation
                if prop.null:
            AttributeError: 'GenericForeignKey' object has no attribute 'null'
ERROR    -  Error reading page 'reference/forms.md':
ERROR    -  Could not collect 'vast_pipeline.forms'

and if you try and ignore this particular error you get to:

 AttributeError: 'ModelFormOptions' object has no attribute 'get_fields'

These errors all stem from the pytkdocs new addition to support Django models:
https://github.com/mkdocstrings/pytkdocs/blob/080079ff693190271733c4e08fb6fb4ddc0aa6ee/src/pytkdocs/loader.py#L724-L751

My understanding is that GenericForeignKey is not a standard Django model object and hence why it fails on this check.

But it's unfortunate that it's such a regression that a lot of files don't process the docstrings whereas they currently do at least generate something. I'm unsure if this is a mistake on the pipeline side or pytkdocs needs to be edited such that it has fallback options rather than just crashing out.

But currently pytkdocs should not be updated to > 0.11.1.