Add support for tags and include responses without content

[Aedial]

The exact implementation of responses without content is still to be decided

[Aedial]

There are 2 versions of parse_responses(), the legacy one that doesn't return any empty response and parse_responses_with_none(), which returns the empty responses alongside the others.
I ran the tests, and both seem to work against the test suite, but some dependents might rely on the specific behavior of the legacy one.
Adding include_empty_models directly to parse_responses() would have been tempting, but it would break the signature that seems to define the parse_*() functions (and breaks inheritance on dependents).

[Aedial]

Merging this PR would solve koxudaxi/fastapi-code-generator#114, koxudaxi/fastapi-code-generator#176 and koxudaxi/fastapi-code-generator#207 (if I understood these correctly).
I already have working code for these issue, waiting for this PR to go through.

[codecov]

Codecov Report

Base: 100.00% // Head: 100.00% // No change to project coverage 👍

Coverage data is based on head (e404bca) compared to base (e9b6edf).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@             Coverage Diff             @@
##            master      #924     +/-   ##
===========================================
  Coverage   100.00%   100.00%             
===========================================
  Files           11        21     +10     
  Lines         1020      2603   +1583     
  Branches       201       614    +413     
===========================================
+ Hits          1020      2603   +1583     

Flag	Coverage Δ
unittests	99.92% <99.90%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
datamodel_code_generator/model/__init__.py	100.00% <ø> (ø)
datamodel_code_generator/__init__.py	100.00% <100.00%> (ø)
datamodel_code_generator/__main__.py	100.00% <100.00%> (ø)
datamodel_code_generator/format.py	100.00% <100.00%> (ø)
datamodel_code_generator/http.py	100.00% <100.00%> (ø)
datamodel_code_generator/imports.py	100.00% <100.00%> (ø)
datamodel_code_generator/model/base.py	100.00% <100.00%> (ø)
datamodel_code_generator/model/enum.py	100.00% <100.00%> (ø)
...atamodel_code_generator/model/pydantic/__init__.py	100.00% <100.00%> (ø)
...amodel_code_generator/model/pydantic/base_model.py	100.00% <100.00%> (ø)
... and 18 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[koxudaxi]

@Aedial
Thank you for creating the PR.
Should we add the option to call the new methods?

[Aedial]

@koxudaxi So, if I understand well, the "right" way would be to add another parameter to OpenAPIParser (datamodel_code_generator/parser/openapi.py#L244), generate (datamodel_code_generator/init.py#L200), and arg_parser (datamodel_code_generator/main.py#L349) ? I was fearing contributing to uncontrolled organic growth going this route, but it seems it is fine by you.

[koxudaxi]

I think we can add tags to the enum for the option. '--openapi-scopes'

datamodel-code-generator/datamodel_code_generator/__main__.py

Lines 102 to 108 in 10ae94f

	arg_parser.add_argument(
	'--openapi-scopes',
	help='Scopes of OpenAPI model generation (default: schemas)',
	choices=[o.value for o in OpenAPIScope],
	nargs='+',
	default=[OpenAPIScope.Schemas.value],
	)

datamodel-code-generator/datamodel_code_generator/__init__.py

Lines 170 to 172 in 10ae94f

	class OpenAPIScope(Enum):
	Schemas = 'schemas'
	Paths = 'paths'

I was fearing contributing to uncontrolled organic growth going this route, but it seems it is fine by you.
I don't find a good solution to avoid the growth now 😅
If some want the option for none content response option, I will think about it again.

[koxudaxi]

Do we need tags' logic in datamodel-code-generator?
We can write the method in fastapi-code-generator.

[Aedial]

Do we need tags' logic in datamodel-code-generator? We can write the method in fastapi-code-generator.

Putting the tags handling in fastapi-codegen makes things awkward, as it would mean putting a special clause for tags in parse_operation (fastapi-code-generator/parser.py), while keeping it in datamodel-code-generator stays consistent with the rest (parse_parameters, parse_request_body, parse_responses) and keeps the logic of Operation in one place. From a "separation of responsibilities" point of view, it feels cleaner.

[Aedial]

Just realized I never committed the tests (oops)

[koxudaxi]

@Aedial
I'm sorry for my late reply.
I misunderstood. We don't need the new arguments of CLI.
We should add the argument for the parser.