search

dlang / dub

Package and build management system for D
MIT License
674 stars 230 forks source link

nonsensical unresolvable dependencies message #2695

Closed WebFreak001 closed 1 month ago

WebFreak001 commented 1 year ago

in my project:

   Upgrading project in /home/webfreak/dev/serve-d/
Error Unresolvable dependencies to package automem:
  cachetools 0.4.1 depends on automem >=0.0.0
  concurrency 5.0.3 depends on automem 0.6.4

while obviously automem 0.6.4 would satisfy the printed constraints.

When trying to dub upgrade a package with the following recipe contents:

dependency "cachetools" version="0.4.1"
dependency "concurrency" version="5.0.3"

the error messages get even worse:

   Upgrading project in /tmp/a/
Error Unresolvable dependencies to package unit-threaded:
  automem 0.6.4 depends on unit-threaded >=0.0.0
  automem 0.6.4 depends on unit-threaded >=0.0.0
  automem 0.6.4 depends on unit-threaded >=0.0.0
  cachetools 0.4.1 depends on unit-threaded ~>0
  concurrency 5.0.3 depends on unit-threaded >=0.0.0
  concurrency 5.0.3 depends on unit-threaded >=0.0.0
  concurrency 5.0.3 depends on unit-threaded >=0.0.0
  ikod-containers 0.0.22 depends on unit-threaded >=0.0.0
Geod24 commented 10 months ago

@WebFreak001 : That would be a good target for a unittest with the new system. Would you like to have a go at it ?

vladimmi commented 2 months ago

Almost a year later it's still an issue. Same, dub upgrade with serve-d:

Error Unresolvable dependencies to package libdparse:
  libddoc 0.8.0 depends on libdparse >=0.13.0 <1.0.0
  serve-d:workspace-d ~master depends on libdparse ~>0.23.0

Without even "0.0.0" stuff above it somehow fails.

grillo-delmal commented 2 months ago

I also stumbled with this problem

Error Unresolvable dependencies to package mir-linux-kernel:
  mir-random 2.2.19 depends on mir-linux-kernel >=1.0.0 <1.3.0
  vibe-d:crypto 0.9.8 depends on mir-linux-kernel ~>1.0.0

But I found what the problem source is. This problem triggers if a dependency can be resolved with a higher version that it's incompatible with the dependency of a library that still has not been resolved. This means that 3 things have to happen at the same time.

1) 2 libraries need to have the same dependency 2) A library version of the dependency needs to exist that can resolve one of them but is too high for the other one 3) The one that can get resolved with a higher version must be resolved first by dub

grillo-delmal commented 2 months ago

Here is a minimal set of files to reproduce the problem

I wrote a reproduction test case at #2959 :)