openapi-python-client doesn't find autoflake even when on $PATH

Beginne bei openapi_python_client/init.py ungefähr in Zeile 157 und reproduziere den Bericht mit einer virtuellen Umgebung, autoflake auf PATH und der bereitgestellten openapi.yaml. Verfolge, wie der Generierungsbefehl autoflake aufruft, und überprüfe, dass die Generierung erfolgreich ist, wenn die ausführbare Datei auf PATH verfügbar ist.

Describe the bug
Even when autoflake is on the PATH, openapi-python-client seems to claim it isn't.

To Reproduce
Steps to reproduce the behavior:

⊙  python3.10 -m venv venv && venv/bin/python -m pip install --quiet openapi-python-client

⊙  ls venv/bin/
Activate.ps1  activate.csh   autoflake  blackd  isort                   openapi-python-client  pip3     pyflakes  python3
activate      activate.fish  black      httpx   isort-identify-imports  pip                    pip3.10  python    python3.10

⊙  PATH=venv/bin:$PATH

⊙  type -a openapi-python-client
openapi-python-client is venv/bin/openapi-python-client

⊙  type -a autoflake
autoflake is venv/bin/autoflake

⊙  autoflake --help
<help output>

⊙  openapi-python-client generate --path openapi.yaml
Generating foo-client
Error(s) encountered while generating, client was not created

autoflake failed

/bin/sh: autoflake: command not found



If you believe this was a mistake or this tool is missing a feature you need, please open an issue at https://github.com/openapi-generators/openapi-python-client/issues/new/choose

Expected behavior
autoflake is found

OpenAPI Spec File

openapi: 3.0.1
info:
  title: Foo
  description: bar`
  contact:
    email: foo@example.com
  version: 0.1.0
servers:
- url: example.com
tags:
- name: foo
  description: |
      bar
paths:
  "/baz":
    responses:
      get:
        tags:
        - foo
        summary: List foo
        operationId: listFoo
        parameters:
        responses:
          "200":
            description: Foo
            content:
              application/json:
                schema:
                  type: array
                  items:
                    type: number

Desktop (please complete the following information):

⊙  uname -a                                                                                                                                                                         julian@Airm
Darwin Airm.local 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:35 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T8101 arm64 arm Darwin

~/Desktop/test 
⊙  venv/bin/python --version                                                                                                                                                        julian@Airm
Python 3.10.7

~/Desktop/test 
⊙  venv/bin/openapi-python-client --version                                                                                                                                         julian@Airm
openapi-python-client version: 0.11.6

Additional context
I haven't investigated carefully yet, though I'm possibly happy to do so after getting my client working, but I suspect the issue is here:

https://github.com/openapi-generators/openapi-python-client/blob/9cea5af550a629415874fb4007e57774af9a5382/openapi_python_client/__init__.py#L157

where commands are executed in a subshell.

As I say I definitely don't fully understand the internals of the project, but generally I think using shell=True is worth trying to avoid as often as possible. I suspect here from what I see, someone can specify arbitrary commands to run post-generation and is doing so as a str in the config? If it's not appealing to change that instead to be a list (and then you don't need shell=True), you could also use shlex.split, which is equally a bit fiddly but would mean you don't spawn a subshell. Or alternatively you could assume the things are installed to the same Python interpreter as openapi-python-generator, and invoke python -m black or python -m autoflake by using sys.executable on the same Python openapi-python-generator is run with, without needing to search $PATH.