Support non-schema components and references (e.g. parameters)

[Aniketghumed]

Describe the bug
When building the client with the path parameter in the yaml file which are passed through reference, it does not consider the parameter and the generated client does not have those referenced parameters.

To Reproduce
Steps to reproduce the behavior:

1. Take any open api sample yaml file that have path parameters in it.
2. Pass that parameter as reference like for example,
   parameters:
   - $ref: '#/components/parameters/sampleparam'
3. Generate client using command "openapi-python-client generate --path <yaml_path>"

Expected behavior
It should consider the path parameters passed through reference too same as the parameters that it considers when passed with the standard way.

OpenAPI Spec File
Any openapi spec file could be used.

Desktop (please complete the following information):

• OS: macOS 10.15.6
• Python Version: 3.7.3
• openapi-python-client 0.7.3

Additional context
It does not raise any error while building the client, but it does not have the referenced parameters in the generated client.

[dbanty]

I believe the only shared components supported right now are actually schemas (the only ones I've ever used 😅). Now that I have a real world example of someone using other components, I guess it's time to plan support!

[kuta42]

I'm willing to help implement this. Can you give a brief overview of how to do it?

[dbanty]

It might be fairly complex, but you're welcome to give it a shot! Parameters specifically are added in openapi_python_client.parser.openapi.Endpoint.add_parameters. Right now references are skipped right at the beginning of the processing loop, so I assume switching that to an if/do_something would be the move.

References to schemas are tracked in openapi_python_client.parser.properties.schemas.Schemas along with any other to-be-generated classes (to prevent duplication). Tracking other references there feels like the right place, but renaming that class would probably make sense since it won't just be schemas anymore?

openapi_python_client.parser.properties.build_schemas is where that Schemas object is constructed. It also assumes that all references its processing are #/components/schemas so that probably requires tweaking as well.

Hopefully that's enough to get you started if you want to give this a shot, like I said though I think this one will be pretty complex since parameters don't even really exist as a concept in the source right now except within an Endpoint.

[kuta42]

if you want to give this a shot, like I said though I think this one will be pretty complex

Then I think it'll require more time than I'm likely to have available.

[dbanty]

Then I think it'll require more time than I'm likely to have available.

I understand completely 😁

[tardyp]

Here is an example json I have crafted from a more complex API which wasn't working as expected

{
    "openapi": "3.0.0",
    "info": {
        "title": "test",
        "version": "1.0.0"
    },
    "paths": {
        "/{id}": {
            "parameters": [
                { "$ref": "#/components/parameters/jobid" }
            ],
            "get": {
                "responses": {
                    "200": { "$ref": "#/components/responses/200" }
                }
            }
        }
    },
    "components": {
        "parameters": {
            "jobid": {
                "in": "path",
                "name": "id",
                "required": true,
                "schema": {
                    "type": "string"
                },
                "description": "Job identifier"
            }
        },
        "responses": {
            "200": {
                "description": "Succeeded"
            }
        }
    }
}

In order to get this implemented quickly, wouldn't it make sense to just preprocess the json and replace every "$ref" by their equivalent?

[adelevie]

Is this slated for development? I am somewhat new to openapi, but I am happy to try and help out if feasible.

[dbanty]

Is this slated for development? I am somewhat new to openapi, but I am happy to try and help out if feasible.

I don't believe anyone is working on this currently, so feel free to give it a shot. I don't have much time to implement stuff myself right now but I am still reviewing/merging stuff periodically 😅.

[adelevie]

@dbanty I'll kick the tires, no guarantees.

Anything I should consider other than what's written in:

• https://github.com/openapi-generators/openapi-python-client/blob/main/CONTRIBUTING.md
• Support non-schema components and references (e.g. parameters) #288 (comment)
  ?

[dbanty]

Only what I commented above about roughly where the implementation should probably go. We preprocess components first, just need to also process and store the non-schema components.

Then those can be referenced later when processing the schemas and building params.

[BobDenny]

Here's YAML and an output log.
YamlAndLog.zip

[dbanty]

The scope of this issue was bigger than just #/components/parameters, but I think new issues should be opened for including other types of references in the future.