openapi-generators / openapi-generators/openapi-python-client
openapi-python-client doesn't find autoflake even when on $PATH
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2k
- Forks
- 293
- Avg merge
- 34m
- Merged PRs (30d)
- 1
Description
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:
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at openapi_python_client/init.py around line 157 and reproduce the report with a virtual environment, autoflake on PATH, and the supplied openapi.yaml. Trace how the generation command invokes autoflake and verify that generation succeeds when the executable is available on PATH.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100