Skip to content

Loosen black requirements, and add stricter ones as a dev dependency #411

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
christhekeele opened this issue May 5, 2021 · 3 comments · Fixed by #416
Closed

Loosen black requirements, and add stricter ones as a dev dependency #411

christhekeele opened this issue May 5, 2021 · 3 comments · Fixed by #416
Labels
🐞bug Something isn't working
Milestone

Comments

@christhekeele
Copy link
Contributor

christhekeele commented May 5, 2021

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

  1. Install python 3.9.4
  2. pip install pipenv
  3. Create a Pipfile with the content below
  4. Run pipenv install --dev --pre and 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 = true
output
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.

@christhekeele christhekeele added the 🐞bug Something isn't working label May 5, 2021
@dbanty
Copy link
Collaborator

dbanty commented 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 do black = "*" for the requirement. I think pip (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. Our poetry.lock file should ensure that internal developers and CI stick on the same version (that's the whole point of it).

@dbanty dbanty added this to the Next milestone May 7, 2021
@christhekeele
Copy link
Contributor Author

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).

I'm definitely experimenting with something outside of the original use-case here, appreciate you taking the time to accommodate it! 😀

@christhekeele
Copy link
Contributor Author

Our poetry.lock file should ensure that internal developers and CI stick on the same version

That makes good sense. I'll shoot a PR over to relax the reqs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants