Abhängigkeitshölle mit Python

Im Vigilant Crypto Snatch Projekt nutze ich Python als Programmiersprache und Poetry zum Verwalten der Abhängigkeiten. Dabei hat sich mit der Zeit einiges angesammelt:

[tool.poetry.dependencies]
BitstampClient = "^2.2.8"
appdirs = "^1.4.4"
coloredlogs = "^15.0"
python = "^3.7.1,<3.11"
pyyaml = "^6.0"
requests = "^2.25.1"
sqlalchemy = "^1.4.27"
urllib3 = "^1.26.3"
krakenex = "^2.1.0"
python-dateutil = "^2.8.2"
click = "^8.0.0"
ccxt = "^1.74.11"

pandas = { version = "^1.3.4", optional = true }
scipy = { version = "^1.7.2", optional = true }
streamlit = { version = "^1.2.0", optional = true }
altair = { version = "^4.1.0", optional = true }
PySide6 = { version = "^6.3.0", optional = true }

Das Problem dabei ist, dass jedes dieser Pakete wieder neue Abhängigkeiten reinzieht. So hängt Streamlit wieder von Click ab, jedoch in einer älteren Version. So hatte Streamlit früher maximal Click 7 unterstützt. Ich musste also erst Streamlit aktualisieren, bevor ich Click 8 nutzen konnte. Poetry löst diese Abhängigkeiten alle auf und erstellt dann eine Liste mit allen Versionen, die passend sind.

Lässt man das durchlaufen, so erhält man alle transitiven Abhängigkeiten. Und das sind aktuell 159 Pakete:

  1. aiodns
  2. aiohttp
  3. aiosignal
  4. altair
  5. appdirs
  6. argon2
  7. async_timeout
  8. attr
  9. attrs
  10. backcall
  11. backports
  12. bitstamp
  13. black
  14. black_primer
  15. blackd
  16. bleach
  17. blib2to3
  18. blinker
  19. bs4
  20. cachetools
  21. ccxt
  22. certifi
  23. cffi
  24. cfgv
  25. charset_normalizer
  26. click
  27. coloredlogs
  28. coverage
  29. cryptography
  30. dateutil
  31. dateutil-stubs
  32. debugpy
  33. decorator.py
  34. defusedxml
  35. distlib
  36. entrypoints.py
  37. fastjsonschema
  38. filelock
  39. frozenlist
  40. ghp_import.py
  41. git
  42. gitdb
  43. google
  44. greenlet
  45. humanfriendly
  46. identify
  47. idna
  48. importlib_metadata
  49. importlib_resources
  50. iniconfig
  51. ipykernel
  52. ipykernel_launcher
  53. IPython
  54. ipython_genutils
  55. ipywidgets
  56. jedi
  57. jinja2
  58. jsonschema
  59. jupyter
  60. jupyter_client
  61. jupyter_core
  62. jupyterlab_pygments
  63. jupyterlab_widgets
  64. krakenex
  65. markdown
  66. markupsafe
  67. material
  68. materialx
  69. matplotlib_inline
  70. mergedeep
  71. mistune.py
  72. mkdocs
  73. multidict
  74. mypy
  75. mypy_extensions
  76. mypyc
  77. nbclient
  78. nbconvert
  79. nbformat
  80. nest_asyncio
  81. nodeenv
  82. notebook
  83. numpy
  84. packaging
  85. pandas
  86. pandocfilters
  87. parso
  88. pathspec
  89. pexpect
  90. pickleshare.py
  91. PIL
  92. pip
  93. piplicenses.py
  94. pkg_resources
  95. platformdirs
  96. pluggy
  97. pre_commit
  98. prettytable
  99. prometheus_client
  100. prompt_toolkit
  101. protobuf
  102. psutil
  103. ptyprocess
  104. pvectorc
  105. py
  106. pyarrow
  107. pycares
  108. pycparser
  109. pydeck
  110. pygments
  111. pymdownx
  112. pympler
  113. pyparsing
  114. pyrsistent
  115. PySide6
  116. pytest
  117. pytz
  118. pytz_deprecation_shim
  119. requests
  120. requests-stubs
  121. scipy
  122. semver.py
  123. send2trash
  124. setuptools
  125. shiboken6
  126. six
  127. smmap
  128. soupsieve
  129. sqlalchemy
  130. sqlalchemy-stubs
  131. sqlmypy
  132. sqltyping
  133. streamlit
  134. terminado
  135. tinycss2
  136. tlz
  137. toml
  138. tomli
  139. toolz
  140. tornado
  141. traitlets
  142. typing_extensions
  143. tzdata
  144. tzlocal
  145. urllib3
  146. urllib3-stubs
  147. validators
  148. virtualenv
  149. watchdog
  150. wcwidth
  151. webencodings
  152. wheel
  153. widgetsnbextension
  154. yaml
  155. yaml-stubs
  156. yaml_env_tag
  157. yarl
  158. zipp
  159. zmq

Das ist der totale Wahnsinn. Also irgendwie ist die Zahl noch klein gegen das, was man so mit JavaScript und NPM in ein Projekt reinzieht, aber ich finde das inzwischen nicht mehr lustig.

Es führt auch zu Problemen. So hat sich beim Streamlit die API etwas geändert. Ich wollte alles aktualisieren. Also habe ich einfach poetry update ausgeführt. Nach 40 Minuten ist mein Laptop abgestürzt, weil der Abhängigkeitslöser (SAT-Solver) von Poetry die verbleibenden 5 GB Arbeitsspeicher genommen hatte und dann der Arbeitsspeicher ausgegangen ist. Und somit kann ich aktuell einfach keine Aktualisierung der Pakete vornehmen.

Das ist ein echtes Problem und ich kann nicht mehr an dem Projekt entwickeln, ohne dass ich da Pakete rauswerfe. Oder eine andere Methode zur Verwaltung der Abhängigkeiten nehme. Das ist wirklich sehr frustrierend.