lock python package dependency versions
während ich an der einrichtung eines deb-repos für stadtgestalten arbeitete, wollte ich eben den aktuellen build von stadtgestalten erneut anstoßen. das hat leider nicht geklappt. das log offenbart warum:
File "/builds/stadtgestalten/stadtgestalten/core/markdown.py", line 8, in <module>
from pymdownx import magiclink
File "/builds/stadtgestalten/stadtgestalten/gitlab-ci-build-venv/lib/python3.5/site-packages/pymdownx/magiclink.py", line 32, in <module>
from markdown.inlinepatterns import LinkInlineProcessor, InlineProcessor
ImportError: cannot import name 'LinkInlineProcessor'
in 1be423bd haben wir das markdown
paket auf <3
festgelegt. das erscheint mir sinnvoll und war zum zeitpunkt des releases völlig unproblematisch. zum jetzigen zeitpunkt wurde aber pymdown-extensions
upstream auf die neue version von markdown
aktualisiert und verwendet imports aus einer version 3+. im release24 branch ist inzwischen pymdown-extensions<6
als dependency hinterlegt.
die lösung für dieses problem ist üblicherweise ein lock file (wie z.B. die package-lock.json
), die den versionsstand von abhängigkeiten für ein release reproduzierbar macht. leider hat pip von haus aus keinen support für solche lockfiles. pipenv hingegegen schon!
mein vorschlag ist, dass wir schnellstmöglich zu pipenv wechseln. zu prüfen wäre, wie sich pipenv in unsere build-tools (namentlich dh-virtualenv
) integriert.
alternativ könnten wir die versionen auch in der requirements.txt
festsetzen und bei bedarf aktualisieren. dann müssten wir aber auch dafür sorge tragen, regelmäßig zu schauen, welche pakete aktualisiert werden können und sollten. eine schwächere option wäre in der requirements.txt
eine version range zu definieren, die immer das nächste major release ausspart und darauf zu hoffen, dass kein projekt die regeln von semantic-versioning ignoriert.
meinungen?