-
-
Notifications
You must be signed in to change notification settings - Fork 424
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
Resolution going in loop #627
Comments
Having same issue with
PDM version 1.10.2
|
It is hard for me to reproduce if you don't provide the full dependency set and |
I extracted some common dependencies in both reports, but can't manage to reproduce:
|
I started a new project via and just added or tried to add 2 dependencies individually and together on various python versions from 3.6.8/3.7.0/3.9.6/3.10.0 pyproject.toml
Notably the same things with copier-poetry which is poetry based vs pdm works fine and its pyproject.toml file looks like this.
The associated poetry.lock file if that is helpful.The associated poetry.lock file if that is helpful.
I was hoping to be able to switch from poetry to pdm but until this issue is resolved doesn't look like i can yet. I would just try to start a test project from : https://github.com/pawamoy/copier-pdm which is the Original posters thing and add one of the applicable things me or him mentioned. I do agree it seem possibly related to those 'mkdocs, autoflake, flake8, black, python>=3.6' ones as those are the primary ones it shows when its stuck in a loop till it times out. Thanks for your time and care into looking into it. This project looks pretty compelling and looking forward to using it in depth in the future ;) |
I noticed nothing: after first generating a project, and starting the locking process, the resolution goes in a loop. If I interrupt it, and restart the locking process, it manages to finish resolving the deps. Just as if something got cached during the loop, that PDM was only able to use after restarting the locking process. |
Anyone would volunteer to try to reduce the number of dependencies for reproducing the problem? It is a headache waiting for a long locking process and seeing success. Sorry but I just don't have enough energy to debug this issue. |
I'll try to find some time @frostming 🙂 |
Experiencing the same issue with the latest pdm version in a couple of projects. Unfortunately, my project has a lot of dependencies (some of them private) so I can't provide a minimal example. |
Here is a reduced set: [build-system]
requires = ["pdm-pep517"]
build-backend = "pdm.pep517.api"
[project]
name = "pawamoy-testing"
version = "0.0.0"
description = "Testing this great template"
authors = [{name = "Timothee Mazzucotelli", email = "pawamoy@pm.me"}]
license = {file = "LICENSE"}
readme = "README.md"
requires-python = ">=3.6.2"
dependencies = []
[tool.pdm]
package-dir = "src"
[tool.pdm.dev-dependencies]
dev = [
"duty~=0.7",
"mkdocs-literate-nav~=0.4; python_version >= '3.7'",
"autoflake~=1.4",
"flake8-comprehensions~=3.7",
"flake8-docstrings~=1.6",
"flake8-string-format~=0.3",
"flake8-tidy-imports~=4.5",
"pytest-cov~=3.0",
"pytest-xdist~=2.4",
] To replicate:
pdm lock
pdm add dependenpy -v # loop Note that if I don't lock before adding the package (i.e. if I do |
#746 seems to fix the issue 🚀 Thanks! |
After updating the pdm by running installer again Thanks for resolving the issue @frostming looking forward to testing stuff out further now. |
Steps to reproduce
Try resolving the following dependencies:
Actual behavior
The resolution will run until it reaches the ResolutionTooDeep limit.
The problematic rounds show items more than once (duplicates).
Something like this (click to expand):
I was not able yet to reduce to the minimal set of dependencies triggering the issue. I'll try to find the time to do it.
However if I remove some of the dependencies, PDM breaks out of the loop (or does not enter in one), and shows an actual resolution error, which is:
(Again, duplicate lines)
Of course if I depend on
importlib-metadata~=3.0
inpyproject,toml
, PDM is able to resolve. I just wanted to give a repro of the resolution loop, because it made it hard to understand what the actual issue was 🙂Also, I can't confirm yet, but I think Poetry's resolver suffers from the same issue.
Expected behavior
No loop, show the actual incompatibilities.
Environment Information
The text was updated successfully, but these errors were encountered: