Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Christopher Arndt <chris@chrisarndt.de>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] pip-compile
Date: Fri, 24 Mar 2017 20:20:37 +0100
Lines: 155
Message-ID: <mailman.63.1490383256.2603.python-de@python.org>
References: <7114c89d-e014-b782-43ba-7c7df073d91a@thomas-guettler.de> <4e9c78a6-add4-6f63-c482-c40064d388b3@chrisarndt.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5VDOK5hmKKnUBPcXSs6TThJWLPD8dr94W"
Openpgp: id=F0BA1EAE86651989C0A1C9901E0D97B33A4E1F31
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
In-Reply-To: <7114c89d-e014-b782-43ba-7c7df073d91a@thomas-guettler.de>
Precedence: list
Xref: csiph.com de.comp.lang.python:4721

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5VDOK5hmKKnUBPcXSs6TThJWLPD8dr94W
Content-Type: multipart/mixed; boundary="Jl0lh5ELUwIO5A79FmL9K0EbiwS0wMhmg";
 protected-headers="v1"
From: Christopher Arndt <chris@chrisarndt.de>
To: Die Deutsche Python Mailingliste <python-de@python.org>
Message-ID: <4e9c78a6-add4-6f63-c482-c40064d388b3@chrisarndt.de>
Subject: Re: [Python-de] pip-compile
References: <7114c89d-e014-b782-43ba-7c7df073d91a@thomas-guettler.de>
In-Reply-To: <7114c89d-e014-b782-43ba-7c7df073d91a@thomas-guettler.de>

--Jl0lh5ELUwIO5A79FmL9K0EbiwS0wMhmg
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hallo Thomas und andere Interessierte,

Am 23.03.2017 um 12:07 schrieb Thomas G=FCttler:
> Ich verstehe nicht so richtig warum dieser Ablauf von pip-tools[1]
> verwendet wird.

ich fange mal mit einer allgemeinen Antwort auf deine letzte Frage an:

> Warum sollte man mit den pip-tools die req.txt Dateien aktualisieren?

* Es m=FCssen in den Eingabe-Dateien nur idR die direkten Abh=E4ngigkeite=
n
definiert werden.
* Die erzeugten Requirements-Dateien pinnen direkte und indirekte
Abh=E4ngigkeiten.
* Beim Erstellen der Requirements wird sichergestellt, dass die
gepinnten Versionen auch verf=FCgbar sind, ...
* ... und dass der geforderte Abh=E4ngigkeitsgraph aufl=F6sbar ist, ...
* und dies auch bei Requirements-Dateien, die von einander abh=E4ngen,
z.B. 'production.txt'->'base.txt' und 'dev.txt'->'base.txt'
* Man kann die geforderten Versionen einzelner Dependencies =E4ndern, ohn=
e
dass das unbeabsichtige =C4nderungen bei anderen Abh=E4ngigkeiten hat.

> Ich sehe das so: in setup.py install_requires sind die ungenauen
> Abh=E4ngigkeiten eingetragen (kein Pinning).

> irgendwie ist es eine endlose Quelle von Verwirrungen, dass es in der
> Python Welt zwei Wege f=FCr die Definition von
> Abh=E4ngigkeiten gibt (setup.py/install_requires und req.txt).

"ungenauen" ist etwas ungenau :) In den "install_requires" werden die
abstrakten Abh=E4ngigkeiten festgelegt, die die Software braucht. D.h.
hier d=FCrfen idR keine festen Versionen gepinnt werden (!) sondern
h=F6chstens Mindestversionen und u.U. Maximalversionen der Abh=E4ngigkeit=
en.

Die install_requires werden verwendet, wenn aus der Software ein (TGZ,
Wheel, Egg)-Paket gebaut wird und dieses dann via easy_install oder pip
installiert wird. Hast du nun eine Anwendung X, und diese will Paket A
und B installieren, und Paket A hat in seiner setup.py stehen
'install_requires =3D ["C=3D=3D1.0"]' und Paket B hat in seiner setup.py
stehen 'install_requires =3D ["C=3D=3D2.0"]' kommmt es zu einem
Versionskonflikt: die Abh=E4ngigkeiten deiner Software lassen sich nicht
mehr installieren.

In den Requirements-Dateien dagegen stehen nicht die Abh=E4ngigkeiten
deiner Anwendung, sondern eine m=F6gliche L=F6sung des Abh=E4ngigkeitsgra=
phen.
Diese stellt eine Beschreibung der Python-Umgebung f=FCr deine Anwedung
dar (Pythonversion, Rechner-Architektur, und OS jetzt mal au=DFen vor
gelassen). Dieser Stand wird installiert, gegen diesen laufen die Tests
und diesen will man auf dem Produktionssystem gleicherma=DFen herstellen.=

Das heisst, in den Requierements-Dateien will ich die genauen Versionen
aller Abh=E4ngigkeiten pinnen, denn nur f=FCr diese ist getestet, dass si=
e
sich alle gemeinsam installieren lassen und nur gegen diese sind die
Ergebnisse der Tests valide.

> Dann l=E4uft das CI und wenn alles ok ist, dann wird eine req.txt per "=
pip
> freeze" erstellt.
> Dies erstelle req.txt enth=E4lt dann das Ergebnis des CI: dieser Stand
> (alles version-pinned) ist erfolgreich getestet worden.

Ja, aber wenn du dann die Version einer Dependency aktualisieren willst,
was machst du dann?

* Trage ich die neue Version einfach in die Requierements-Datei ein, ist
nicht sichergestellt, dass sich die neue Version =FCberhaupt mit den
sonstigen Versionen, die in der Requirementsdate gepinnt sind,
installieren l=E4sst.
* Installiere ich die neue Version einfach mit "pip install -U XYZ",
werden h=F6chstwahrscheinlich weitere Abh=E4ngkeiten aktuaisiert und es
findet keine Pr=FCfung statt, ob deren neue Versionen mit meiner Anwendun=
g
kompatibel sind. Wo sollte eine solche Einschr=E4nkung dokumentiert werde=
n?
* Installiere ich die neue Version mit "pip install -U --no-deps XYZ",
bekommme ich mit einem "pip freeze" danach einen Stand meiner Umgebung,
der sich u.U. gar nicht mehr mit "pip install -r requirements.txt"
installieren l=E4sst, weil die gepinnten Versionen nicht mehr zum
Abh=E4ngigkeitsgraphen passen.

Mit pip-tools erh=F6he ich einfach die Mindestversion der Abh=E4ngigkeit =
in
der requirements.in Datei, lasse dann nochmal pip-compile laufen und
habe danach eine valide requirements.txt Datei oder bekomme eben gleich
einen Fehler und wei=DF, dass die Abh=E4ngigkeiten nicht zusammen passen
(und nicht erst, wenn versucht wird, "pip install -r ..." im CI oder gar
erst auf dem Staging/Produktionssystem auszuf=FChren).

Ich hoffe, ich habe die Problematik damit etwas verdeutlichen k=F6nnen.
Hier noch der Link zu einem interessanten Blog-Artikel =FCber einen guten=

Workflow f=FCr pip-tools:

http://jamescooke.info/a-successful-pip-tools-workflow-for-managing-pytho=
n-package-requirements.html

Diesen habe ich hier (mit einigen kleinen Anpassungen) umgesetzt:

https://github.com/SpotlightKid/python-package-cookiecutter/blob/master/%=
7B%7B%20cookiecutter.repo_name%20%7D%7D/requirements/Makefile


Chris




--Jl0lh5ELUwIO5A79FmL9K0EbiwS0wMhmg--

--5VDOK5hmKKnUBPcXSs6TThJWLPD8dr94W
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Puzzled by the all these strange characters?
Comment: See http://tinyurl.com/cehoa7 for an introduction
Comment: to public key encryption and signing.

iQIzBAEBCAAdFiEE8LoeroZlGYnAocmQHg2XszpOHzEFAljVcYUACgkQHg2XszpO
HzFsYw/8CfQPOCZqlriQkf71RkXOD/ilK5zT355UODFFTXik1UyRj0RZ1goOWTRy
/tccftM0QXZjejftaxy+x63aNHmwsy6z5KNI4mymRyolu2qMWe+Khz89ZVzw3k6S
LskdAAp4CDHaqoVwSnfnwVbi0PjSYupG3W2y3OEBJlxn5OUccKJHz1wte/woPqEj
CFbC+p/CtJCV3pct/b2qnbolRKLfAUItF9tJ4kVyUPE5WEExLqj0B7Y73DGdO68p
aLUYus6kU5hCgQ2aFmNF+2rgDkACmyA7A1xDDomSddn0vpTyPP3d/YEM2KN7UFRm
eAWFMuwp8fMwX1Gq7T6Vyz5Byd/qtvKPQ2c7ildjmClgetbI2qCLWWiY1xrkZsSS
ZhyYcGoMMmpfutMlRJWBgG9CisOPu81bQolY9dXwIqNicUHBzkFNX+ltVo0ca11B
YT1NResv6dqTO6BJ1s5bSaTD1LfcER4GoR1I3y3sd9+yDYIHQZ95Sp3lu8sZ+mI0
6A7xAweZ3+PvdEP5uVv2l3aVvTVqKDyLgw37Mhs2JGYaaOJzswrI0PO7H1aRJ2R9
iPkMSlFAqGveSnxYZ/STE/jsmhQzj5OGkce0X79HZ3rXr0qeHVF0eVOfvZONxFM3
rfCKEQNoKj7GXniCOsopoSx5jRUXZqk703QBGX0bAZoXY2mGixc=
=O6Te
-----END PGP SIGNATURE-----

--5VDOK5hmKKnUBPcXSs6TThJWLPD8dr94W--