Hallo, wenn ich das richtig verstehe, ist Dein Paket eine "Bibliothek", ein Plugin, also eine Erweiterung, das mit verschiedenen Django- und Python-Versionen genutzt werden kann? Da möchtest Du die Abhängigkeiten nicht pinnen. Apps und fertige Projekte pinnen die Abhängigkeiten (rekursiv) um den vollen Baum fix zu haben von development über staging zu production. Bzw. von der Kiste des Entwicklers möglichst bis zum distro-package. Bibliotheken/Module, die von vielen Leuten in vielen Projekten mit vielen Versionskombinationen verwendet werden sollen, haben ihre eigenen Abhängigkeiten so frei wie möglich (und testen eben jeweils gegen das Aktuellste der Abhängigkeiten). Vielleicht noch gegen eine Matrix von Pythonversion und den größten Abhängigkeiten in LTS-1, LTS, current. - Arnold On Thu, 4 May 2017 21:54:10 +0200 Jens <python-de-mailingliste@jensdiemer.de> wrote:

Ich würde gern mit pip-compile alle nötigen Abhängigkeiten Festpinnen.

Allerdings sollte mein Paket verschiedenen Django Versionen unterstützen und das noch mit verschiedenen Django-CMS Versionen... Das sollte dann natürlich per tox mit Python 2/3/PyPy durch getestet werden...

Wie das am besten realisieren?!?

1. Verschiedene requirements Dateien? Das werden viele, bei 3 verschiedenen Django Versionen mit drei verschiedenen Django-CMS Versionen...

2. Django und Django-CMS aus den requirements weg lassen? Dann macht pip-compile allerdings nicht so viel Sinn, wenn doch nicht alles abgedeckt ist, oder?

3. auf pip-compile verzichten, weil doof.

Ich hab ein wenig rumgesucht, aber so viele Projekte setzten anscheinen pip-compile nicht ein und wenn, dann kein Django oder eine andere Komponente in Unterschiedlichen Versionen.

Fündig wurde ich bei https://github.com/edx/help-tokens Wobei das recht frisch ausschaut und vielleicht noch praxisfern ist?

Bei diesem Projekt wird in "requirements/base.in" einfach nur "django" angegeben. Für tox wird nach dem "pip-compile" per sed aus der "requirements/test.txt" den "django==xxx" Eintrag gelöscht.