Skip to content
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

Poetry unable to resolve dependency using asterisk wildcard (*) #2687

Closed
3 tasks done
matthewarmand opened this issue Jul 20, 2020 · 9 comments
Closed
3 tasks done

Poetry unable to resolve dependency using asterisk wildcard (*) #2687

matthewarmand opened this issue Jul 20, 2020 · 9 comments
Labels
area/solver Related to the dependency resolver kind/bug Something isn't working as expected

Comments

@matthewarmand
Copy link

Issue

I'm noticing an issue with using a wildcard (*) for a version specification for a dependency in pyproject.toml. In this new project, I'm adding a dev dependency of black for code formatting. Generally I prefer to allow any version for this, so I'm attempting to use the wildcard syntax (docs). The docs seem to indicate that my example gist above should work, but poetry is having trouble resolving the dependency.

In searching for other issues, this seems similar to #1281, though that's an older issue. I tried the mitigation steps at the end of that issue (deleting poetry.lock, etc) but it does not seem to help this case. I also noticed #2626, and I'm wondering if this is somehow related to that issue, perhaps a side effect. Opened this one separately though in case its a different issue.

Sample commands and output

When I try to do this via manual modification of pyproject.toml and using poetry install -vvv, I see the following output:

Using virtualenv: /home/matt/.cache/pypoetry/virtualenvs/example-k3bGbc8x-py3.8
Updating dependencies
Resolving dependencies...
   1: fact: example is 0.1.0
   1: derived: example
   1: fact: example depends on django (~2.2)
   1: fact: example depends on black (*)
   1: fact: example depends on black (*)
   1: selecting example (0.1.0)
   1: derived: black (*)
   1: derived: django (~2.2)
   1: fact: no versions of black match *
   1: conflict: no versions of black match *
   1: ! black (*) is satisfied by black (*)
   1: ! which is caused by "example depends on black (*)"
   1: ! thus: version solving failed
   1: Version solving took 0.017 seconds.
   1: Tried 1 solutions.

[SolverProblemError]
Because example depends on black (*) which doesn't match any versions, version solving failed.

Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/clikit/console_application.py", line 131, in run
    status_code = command.handle(parsed_args, io)
  File "/usr/lib/python3.8/site-packages/clikit/api/command/command.py", line 120, in handle
    status_code = self._do_handle(args, io)
  File "/usr/lib/python3.8/site-packages/clikit/api/command/command.py", line 171, in _do_handle
    return getattr(handler, handler_method)(args, io, self)
  File "/usr/lib/python3.8/site-packages/cleo/commands/command.py", line 92, in wrap_handle
    return self.handle()
  File "/usr/lib/python3.8/site-packages/poetry/console/commands/install.py", line 69, in handle
    return_code = installer.run()
  File "/usr/lib/python3.8/site-packages/poetry/installation/installer.py", line 74, in run
    self._do_install(local_repo)
  File "/usr/lib/python3.8/site-packages/poetry/installation/installer.py", line 161, in _do_install
    ops = solver.solve(use_latest=self._whitelist)
  File "/usr/lib/python3.8/site-packages/poetry/puzzle/solver.py", line 36, in solve
    packages, depths = self._solve(use_latest=use_latest)
  File "/usr/lib/python3.8/site-packages/poetry/puzzle/solver.py", line 190, in _solve
    raise SolverProblemError(e)

Alternatively, I also attempted to let poetry add the dependency using poetry add --dev -vvv black="*". The PyPI lines below seem particularly suspect, so maybe this is related to poetry's PyPI interaction in the wildcard case. In this case, I see the following output:

Using virtualenv: /home/matt/.cache/pypoetry/virtualenvs/example-k3bGbc8x-py3.8
PyPI: 20 packages found for black *

Updating dependencies
Resolving dependencies...
   1: fact: example is 0.1.0
   1: derived: example
   1: fact: example depends on django (~2.2)
   1: fact: example depends on black (*)
   1: fact: example depends on black (*)
   1: selecting example (0.1.0)
   1: derived: black (*)
   1: derived: django (~2.2)
PyPI: No release information found for django-1.0.1, skipping
PyPI: No release information found for django-1.0.2, skipping
PyPI: No release information found for django-1.0.3, skipping
PyPI: No release information found for django-1.0.4, skipping
PyPI: No release information found for django-1.1, skipping
PyPI: No release information found for django-1.1.1, skipping
PyPI: No release information found for django-1.1.2, skipping
PyPI: 15 packages found for django >=2.2,<2.3
PyPI: 0 packages found for black *
   1: fact: no versions of black match *
   1: conflict: no versions of black match *
   1: ! black (*) is satisfied by black (*)
   1: ! which is caused by "example depends on black (*)"
   1: ! thus: version solving failed
   1: Version solving took 0.018 seconds.
   1: Tried 1 solutions.

[SolverProblemError]
Because example depends on black (*) which doesn't match any versions, version solving failed.

Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/clikit/console_application.py", line 131, in run
    status_code = command.handle(parsed_args, io)
  File "/usr/lib/python3.8/site-packages/clikit/api/command/command.py", line 120, in handle
    status_code = self._do_handle(args, io)
  File "/usr/lib/python3.8/site-packages/clikit/api/command/command.py", line 171, in _do_handle
    return getattr(handler, handler_method)(args, io, self)
  File "/usr/lib/python3.8/site-packages/cleo/commands/command.py", line 92, in wrap_handle
    return self.handle()
  File "/usr/lib/python3.8/site-packages/poetry/console/commands/add.py", line 149, in handle
    status = installer.run()
  File "/usr/lib/python3.8/site-packages/poetry/installation/installer.py", line 74, in run
    self._do_install(local_repo)
  File "/usr/lib/python3.8/site-packages/poetry/installation/installer.py", line 161, in _do_install
    ops = solver.solve(use_latest=self._whitelist)
  File "/usr/lib/python3.8/site-packages/poetry/puzzle/solver.py", line 36, in solve
    packages, depths = self._solve(use_latest=use_latest)
  File "/usr/lib/python3.8/site-packages/poetry/puzzle/solver.py", line 190, in _solve
    raise SolverProblemError(e)
@matthewarmand matthewarmand added kind/bug Something isn't working as expected status/triage This issue needs to be triaged labels Jul 20, 2020
@matthewarmand
Copy link
Author

I also did notice this advice at #743 (comment), but nothing else in this project depends on black (at least according to poetry.lock when I remove black) so it seems unlikely that there's some other hidden dependency further constraining the version.

@finswimmer finswimmer added the area/solver Related to the dependency resolver label Jul 27, 2020
@jaklan
Copy link

jaklan commented Aug 6, 2020

Exactly the same issue, also with black.

@peterdeme
Copy link

Yep, asterisk doesn't work with black on 1.0.10.

@wasdee
Copy link
Contributor

wasdee commented Aug 13, 2020

This also affects the version specification in packages with setup.cfg .
akaihola/darker#52

byt3bl33d3r added a commit to byt3bl33d3r/pythoncookie that referenced this issue Oct 11, 2020
Got rid of black cause Poetry has issues with it (python-poetry/poetry#2687)
@mdengler
Copy link

mdengler commented Apr 20, 2021

This issue still exists with poetry 1.0.10 and a dependency on black = "*" in pyproject.toml. A workaround, and observations:

Workaround

Use:

[tool.poetry.dependencies]
black = ">=20.8b1"

...instead of black = "*" or any other version specifier.

Observations

Is this related to the b1 version suffix black currently has?

$ python -m poetry search black | head -4

black (20.8b1)
 The uncompromising code formatter.

After rm -rf poetry.lock .venv:

  1. If I use black = ">=20", poetry install fails
  2. If I use black = ">=19.8b1", poetry install works (?!)
  3. If I remove the dependency on black, poetry install works (with my pyproject.toml).

Environment / versions to reproduce

$ head -2 /etc/os-release
NAME=Fedora
VERSION="33 (Workstation Edition)"

$ python -m poetry --version
Poetry version 1.0.10

$ python -V
Python 3.9.2


$ rm poetry.lock
rm: cannot remove 'poetry.lock': No such file or directory

$ python -m poetry install
Updating dependencies
Resolving dependencies... (0.1s)

[SolverProblemError]
Because PACKAGENAME depends on black (*) which doesn't match any versions, version solving failed.


$ grep -C 3 black pyproject.toml


[tool.poetry.dev-dependencies]
black = "*"
flake8 = "*"
flake8-bugbear = "*"
ipython = "*"
--
[...]


[tool.black]
target-version = ['py38']  # no py39 yet
exclude = '''
(
--
'''

[tool.isort]
profile = "black"
multi_line_output = 3
extra_standard_library = ['pandas', 'numpy', 'dateutil', 'pytz', 'psycopg2', 'sqlalchemy']
color_output = true

$ python -m poetry install
Updating dependencies
Resolving dependencies... (0.1s)

[SolverProblemError]
Because PACKAGENAME depends on black (*) which doesn't match any versions, version solving failed.
$

@matthewarmand
Copy link
Author

Fwiw @mdengler I'm no longer noticing this problem on poetry versions 1.1.x, is there a reason you're stuck on 1.0.x and can't update?

@mdengler
Copy link

Looks like I was just on an old version (thought I had updated to the latest but clearly not). So this bug can be closed?

@matthewarmand
Copy link
Author

Probably yeah. I'd just left it open until a maintainer popped in but that hasn't happened, and since it seems to have been incidentally fixed as of 1.1.x, seems it can be closed.

@abn abn removed the status/triage This issue needs to be triaged label Mar 3, 2022
Copy link

github-actions bot commented Mar 2, 2024

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/solver Related to the dependency resolver kind/bug Something isn't working as expected
Projects
None yet
Development

No branches or pull requests

7 participants