|
|
pip package management system
|
|
|
|
|
|
"pip installs packages"
|
|
|
"preferred installer program"
|
|
|
|
|
|
inkludiert in python
|
|
|
|
|
|
nachfolger von easy_install
|
|
|
|
|
|
Python Software Foundation -> Standards die Formuliert wurden -> Python Package Index Standard -> Implementierung, Standard PyPI
|
|
|
|
|
|
|
|
|
PythonPackageIndex (PyPI) als Standardrepository
|
|
|
Basiert auf der Web Application "Warehouse" - eine implementierung des Python Package Index Standards
|
|
|
------> Das ist das was wir machen!!
|
|
|
|
|
|
|
|
|
- 100.000 Pakete
|
|
|
- Gesponsort von vielen Unternehmen, liegt auf AWS
|
|
|
- Maintained durch PythonPackaging Authority (Bearbeiter von Projekten zentral) und unterstützt von der Python Packaging Working Group (Geldbeschaffer)
|
|
|
|
|
|
|
|
|
-Registrierung erforderlich
|
|
|
- Statistics möglich mit extra Erweiterung (Anbindung an Google BigQuery)
|
|
|
- Lokale Mirrors, eigene Repos möglich
|
|
|
- Erster absender ist der Owner des Packages
|
|
|
- Owner und Maintainer möglich
|
|
|
- Maintainer können Package information editieren, aber nicht neue Owner festlegen
|
|
|
- Owner können Maintainer und neue Owner ernennen
|
|
|
- PyPI stellt website über information zum Paket selbst her
|
|
|
- Öffentliche Profile
|
|
|
- Kein Ranking, Crowdsourced Trust
|
|
|
|
|
|
PythonPackagingAuthority:
|
|
|
- Working group, welche an vielen Projekten bezüglich PyPI arbeitet z.B. pip, twine, pipenv, setuptools
|
|
|
- Keine Kontrolle der hochgeladenen Pakete, allerdings haben sie die Fähigkeit Pakete zu löschen
|
|
|
PyPI application administrators (10 Stück insgesamt) reagieren auf Hinweise bzgl. Malware etc.
|
|
|
|
|
|
|
|
|
|
|
|
Upload:
|
|
|
über Kommandozeile mit dem Befehl twine (früher setup.py, das ist aber gefährlich)
|
|
|
/dist verzeichnis mit relevanten dateien
|
|
|
- login über tui
|
|
|
- absenden des packagename
|
|
|
- upload
|
|
|
|
|
|
Anfällig für Typosquatting
|
|
|
|
|
|
Was wird geuploadet:
|
|
|
Source Distribution
|
|
|
und/oder
|
|
|
Wheels, vorgebuildete pakete
|
|
|
|
|
|
Wheel: Das Paket, löst "eggs" ab.
|
|
|
- Simply unpacking into site-packages mit standard unzip (quasi tar, aber mit mehr metainformationen)
|
|
|
- Keine Semantische Analyse
|
|
|
- Keine Ausführung von Code (anders als bei egg)
|
|
|
|
|
|
|
|
|
Versionierung: Pro Projekt unterschiedlich, aber alle müssen
|
|
|
dem "Public versions identifier" entsprechen
|
|
|
|
|
|
Semantic versioning
|
|
|
- Major.Minor.Maintenance
|
|
|
Major - incompatible API changes
|
|
|
Minor - adding functionality backward compatible
|
|
|
Maintance - bugfixes
|
|
|
|
|
|
Date based versioning
|
|
|
Wie Ubuntu (Vorteil: Alter sofort feststellbar)
|
|
|
YEAR.MONTH
|
|
|
|
|
|
Serial versioning
|
|
|
Increment every release
|
|
|
|
|
|
Pre-release versioning ("nightly")
|
|
|
.devN, .aN, .bN, .rcN
|
|
|
werden standardmäßig ignorierrt
|
|
|
|
|
|
Local versioning:
|
|
|
lokale builds oder spezielle distributionspakete
|
|
|
1.2.1+fedora.4
|
|
|
|
|
|
|
|
|
Testing:
|
|
|
- es gibt eine seperate PyPI Instanz testPyPI um nicht am großen Repo rumzufummeln
|
|
|
- in den Paketen können selbst Testfälle definiert werden, die vom installer aufgerufen werden können (python setup.py test) |