Repository navigation
Loosen black requirements, and add stricter ones as a dev dependency #411
Description
Describe the bug
A clear and concise description of what the bug is.
Hey there! I've run into a situation where I can't resolve my application's black dependency, because this library specifies a particular version in its package manifest.
Based on this PR, it seems like openapi-python-client uses black as a development dependency for formatting its own code. It also requires it as a runtime dependency in consuming projects so it can format its generated code.
Currently, this library declares a dependency on black in the required package manifest. This forces openapi-python-client users to depend on a compatible black version, which is currently a narrow range.
I believe we should require library consumers to use a far less specific version of black (like perhaps just 20+ in general), and then add our preferred version range (currently: black<22.0,>=21.4b0) into the development dependencies instead.
To Reproduce
Steps to reproduce the behavior
- Install python
3.9.4 pip install pipenv- Create a
Pipfilewith the content below - Run
pipenv install --dev --preand see the failure output below
Pipfile
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true
[requires]
python_version = "3.9"
[dev-packages]
# DEVTOOLS
black = "~=20.8b0" # Formatter
openapi-python-client = "~=0.8" # API client lib generator
pipenv = "*"
[pipenv]
allow_prereleases = trueoutput
Creating a virtualenv for this project...
Pipfile: /Users/keele/Projects/oss/bug-reports/Pipfile
Using /Users/keele/.config/asdf/data/installs/python/3.9.4/bin/python3.9 (3.9.4) to create virtualenv...
⠇ Creating virtual environment...created virtual environment CPython3.9.4.final.0-64 in 500ms
creator CPython3Posix(dest=/Users/keele/.local/share/virtualenvs/bug-reports-kpKsivT_, clear=False, no_vcs_ignore=False, global=False)
seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/Users/keele/Library/Application Support/virtualenv)
added seed packages: pip==21.0.1, setuptools==54.2.0, wheel==0.36.2
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
✔ Successfully created virtual environment!
Virtualenv location: /Users/keele/.local/share/virtualenvs/bug-reports-kpKsivT_
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Building requirements...
Resolving dependencies...
✘ Locking Failed!
[ResolutionFailure]: File "/Users/keele/.config/asdf/data/installs/python/3.9.4/lib/python3.9/site-packages/pipenv/resolver.py", line 741, in _main
[ResolutionFailure]: resolve_packages(pre, clear, verbose, system, write, requirements_dir, packages, dev)
[ResolutionFailure]: File "/Users/keele/.config/asdf/data/installs/python/3.9.4/lib/python3.9/site-packages/pipenv/resolver.py", line 702, in resolve_packages
[ResolutionFailure]: results, resolver = resolve(
[ResolutionFailure]: File "/Users/keele/.config/asdf/data/installs/python/3.9.4/lib/python3.9/site-packages/pipenv/resolver.py", line 684, in resolve
[ResolutionFailure]: return resolve_deps(
[ResolutionFailure]: File "/Users/keele/.config/asdf/data/installs/python/3.9.4/lib/python3.9/site-packages/pipenv/utils.py", line 1395, in resolve_deps
[ResolutionFailure]: results, hashes, markers_lookup, resolver, skipped = actually_resolve_deps(
[ResolutionFailure]: File "/Users/keele/.config/asdf/data/installs/python/3.9.4/lib/python3.9/site-packages/pipenv/utils.py", line 1108, in actually_resolve_deps
[ResolutionFailure]: resolver.resolve()
[ResolutionFailure]: File "/Users/keele/.config/asdf/data/installs/python/3.9.4/lib/python3.9/site-packages/pipenv/utils.py", line 833, in resolve
[ResolutionFailure]: raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: Could not find a version that matches black<22.0,>=21.4b0,~=20.8b0 (from -r /var/folders/8c/5ssnllx97txcvkptv3hbx5gr0000gn/T/pipenvjbrakla8requirements/pipenv-l3swafsz-constraints.txt (line 3))
Skipped pre-versions: 18.3a0, 18.3a0, 18.3a1, 18.3a1, 18.3a2, 18.3a2, 18.3a3, 18.3a3, 18.3a4, 18.3a4, 18.4a0, 18.4a0, 18.4a1, 18.4a1, 18.4a2, 18.4a2, 18.4a3, 18.4a3, 18.4a4, 18.4a4, 18.5b0, 18.5b0, 18.5b1, 18.5b1, 18.6b0, 18.6b0, 18.6b1, 18.6b1, 18.6b2, 18.6b2, 18.6b3, 18.6b3, 18.6b4, 18.6b4, 18.9b0, 18.9b0, 19.3b0, 19.3b0, 19.10b0, 19.10b0, 20.8b0, 20.8b1, 21.4b0, 21.4b0, 21.4b1, 21.4b1, 21.4b2, 21.4b2, 21.5b0, 21.5b0
There are incompatible versions in the resolved dependencies:
black~=20.8b0 (from -r /var/folders/8c/5ssnllx97txcvkptv3hbx5gr0000gn/T/pipenvjbrakla8requirements/pipenv-l3swafsz-constraints.txt (line 3))
black<22.0,>=21.4b0 (from openapi-python-client==0.9.0->-r /var/folders/8c/5ssnllx97txcvkptv3hbx5gr0000gn/T/pipenvjbrakla8requirements/pipenv-l3swafsz-constraints.txt (line 4))
Expected behavior
A clear and concise description of what you expected to happen.
I expect to be able to use the version of black my project requires without having to use whatever version openapi-python-client happens to prefer as a dev dependency.
Desktop (please complete the following information):
- OS: macOS 11.2.3 Big Sur
- Python Version: 3.9.4
- openapi-python-client version 0.9.0
Additional context
Add any other context about the problem here.
My specific usecase here: my application uses black v20.8b0 as a development dependency to strictly match the version that the pre-commit tools uses in CI; and it uses openapi-python-client v0.9.0 is a development dependency to generate libraries in CI as well. This version requires black<22.0,>=21.4b0 as a hard dependency.
Activity
dbanty commentedon May 7, 2021
Interesting, I hadn't thought about people using it as a development dependency. The intention was for the generator to be used as a standalone tool (e.g. through
pipx) and not as a library, so its own internal dependencies shouldn't conflict with other ones. However, you bring up a good point that it would be nice for folks to generate code with their version of black anyway. I can't think of a good reason to not doblack = "*"for the requirement. I thinkpip(or whatever) will install the latest compatible version by default but then if people wanted to use a much older version (e.g. 19.10) they're free to do so. Ourpoetry.lockfile should ensure that internal developers and CI stick on the same version (that's the whole point of it).christhekeele commentedon May 7, 2021
I'm definitely experimenting with something outside of the original use-case here, appreciate you taking the time to accommodate it! 😀
christhekeele commentedon May 7, 2021
That makes good sense. I'll shoot a PR over to relax the reqs!