python packaging
1.0.0
PYTHONPATHPanduan Kemasan Python Resmi
Modul di Python adalah file tunggal (dengan ekstensi .py ) yang berisi kode Python. Biasanya terdiri dari kelas, fungsi, dan variabel yang dapat digunakan oleh kode Python lainnya. Modul digunakan untuk mengatur kode menjadi unit logis dan memfasilitasi penggunaan kembali kode.
Misalnya, pertimbangkan modul bernama math_operations.py yang berisi fungsi untuk melakukan operasi matematika seperti penambahan, pengurangan, multiplikasi, dll. Anda dapat mengimpor dan menggunakan fungsi -fungsi ini dalam skrip Python lainnya.
# math_operations.py
def add ( x , y ):
return x + y
def subtract ( x , y ):
return x - y Paket di Python adalah kumpulan modul yang dikelompokkan bersama dalam direktori. Paket biasanya diwakili oleh direktori yang berisi file __init__.py (yang bisa kosong) dan satu atau lebih modul Python. File __init__.py menunjukkan kepada Python bahwa direktori harus diperlakukan sebagai paket.
Misalnya, pertimbangkan paket bernama my_package :
my_package/
├── __init__.py
├── module1.py
└── module2.py
Di sini, my_package adalah paket yang berisi module1.py dan module2.py , yang dapat diimpor menggunakan notasi titik ( my_package.module1 , my_package.module2 ).
Sub-paket dalam Python adalah paket yang bersarang di dalam paket lain. Ini berarti bahwa paket dapat berisi paket lain serta modul. Sub-paket dibuat dengan mengatur direktori dan menambahkan file __init__.py dengan tepat untuk menentukan struktur paket.
Misalnya:
my_parent_package/
├── __init__.py
└── my_sub_package/
├── __init__.py
├── module3.py
└── module4.py
Dalam struktur ini, my_sub_package adalah sub-paket my_parent_package , dan dapat berisi modul sendiri ( module3.py , module4.py ). Sub-paket dapat diimpor menggunakan notasi titik ( my_parent_package.my_sub_package.module3 ).
Paket distribusi (atau hanya distribusi ) dalam Python mengacu pada koleksi paket Python yang dikemas dan sumber daya yang tersedia untuk instalasi. Ini biasanya mencakup modul, paket, file data, file konfigurasi, dan sumber daya lain yang diperlukan untuk tujuan tertentu (misalnya, perpustakaan atau aplikasi).
Paket distribusi sering didistribusikan dan diinstal menggunakan manajer paket Python seperti pip dan dapat diunggah ke repositori paket seperti PYPI (Indeks Paket Python) untuk distribusi dan pemasangan yang mudah oleh pengembang lain.
Misalnya, paket distribusi populer termasuk numpy , fast-api , pandas , dll., Yang dipasang menggunakan pip dan menyediakan fungsionalitas yang dapat digunakan dalam proyek Python.
sdistsetup.pypython setup.py build sdist untuk membangun distribusi sumberpip install ./dist/<package_name>.tar.gz untuk menginstal paketpip list untuk melihat apakah paket diinstal. Jika perubahan dilakukan dalam paket maka gunakan pip install . yang akan membangun dan menginstal paket terbaru dengan cepat.
Atau cukup gunakan yang dapat diedit sehingga Anda tidak selalu harus membangun kembali paket perubahan baru dilakukan:
pip install --editable . sdist adalah kependekan dari distribusi sumber, file .tar yang berisi kode kami yang disebut "SDIST". Artinya adalah bahwa paket distribusi hanya berisi subset dari kode sumber kami.
"Distribusi sumber" pada dasarnya adalah folder zip yang berisi kode sumber kami.
wheel Distribusi Sumber ( sdist ) :
*.py ), file konfigurasi, dan aset terkait proyek lainnya.python setup.py sdist . Roda ( bdist_wheel ) :
sdist ..whl .python setup.py bdist_wheel . Instalasi yang lebih cepat :
*.whl ) biasanya lebih cepat daripada menginstal dari distribusi sumber ( *.tar.gz ).Kemudahan penggunaan untuk pengguna :
sdist dan bdist_wheelsdist dan bdist_wheel untuk paket Python untuk mengakomodasi berbagai kasus penggunaan dan platform.python setup.py sdist bdist_wheelPersyaratan Kompilasi :
Sayangnya, membangun roda untuk semua sistem operasi menjadi sulit jika Anda memiliki langkah kompilasi yang diperlukan, jadi beberapa pemelihara OS hanya membangun roda untuk satu OS.
pip benar -benar menjalankan setup.py (atau file yang setara) di mesin Anda , tepat setelah mengunduh SDIST.Membangun roda mungkin memerlukan kode kompilasi
gcc jika kode sumber dalam C, tetapi bahasa lain memerlukan kompiler mereka sendiri. Pengguna harus menginstal ini pada mesin mereka atau pip install ... hanya akan gagal. Ini bisa terjadi saat Anda menginstal numpy , pandas , scipy , pytorch , tensorflow , dll. setup.py dapat berisi kode sewenang -wenang. Ini sangat tidak aman. setup.py mungkin berisi kode berbahaya.
Manajemen Ketergantungan :
gcc , dll.) Untuk berhasil menginstal paket yang memerlukan kompilasi.Masalah keamanan :
setup.py untuk instalasi paket dapat tidak aman karena menjalankan kode sewenang -wenang.wheelNama file roda dipecah menjadi bagian -bagian yang dipisahkan oleh tanda hubung:
{dist}-{version}(-{build})?-{python}-{abi}-{platform}.whl Setiap bagian dalam {brackets} adalah tag, atau komponen nama roda yang membawa beberapa makna tentang apa yang berisi roda dan di mana roda akan atau tidak akan berfungsi.
Misalnya: dist/packaging-0.0.0-py3-none-any.whl
packaging adalah nama paket0.0.0 adalah nomor Verisonpy3 menunjukkannya untuk python3abi . ABI adalah singkatan dari Application Binary Interface.any yang berdiri untuk bahwa paket ini dibangun untuk bekerja di platform apa pun.Contoh lainnya:
cryptography-2.9.2-cp35-abi3-macosx_10_9_x86_64.whlchardet-3.0.4-py2.py3-none-any.whlPyYAML-5.3.1-cp38-cp38-win_amd64.whlnumpy-1.18.4-cp38-cp38-win32.whlscipy-1.4.1-cp36-cp36m-macosx_10_6_intel.whlAlasannya adalah, file roda berisi kode biner yang sudah dipenuhi yang membantu menginstal paket dengan cepat.
Pemeliharaan Paket :
sdist dan bdist_wheel untuk memaksimalkan kompatibilitas dan kemudahan penggunaan untuk pengguna.Pertimbangkan pengalaman pengguna :
build Alat CLI dan pyproject.toml"Bangun dependensi" adalah apa pun yang harus dipasang pada sistem Anda untuk membangun paket distribusi Anda menjadi SDIST atau roda.
Misalnya, kami perlu pip install wheel untuk menjalankan python setup.py bdist_wheel sehingga wheel adalah ketergantungan build untuk roda bangunan.
File setup.py bisa menjadi rumit.
Anda mungkin perlu pip install ... perpustakaan eksternal dan mengimpornya ke file setup.py Anda untuk mengakomodasi proses pembuatan yang kompleks.
Kuliah menunjukkan pytorch dan airflow sebagai contoh paket dengan file setup.py yang kompleks.
Entah bagaimana Anda harus dapat mendokumentasikan dependensi membangun di luar setup.py .
Jika mereka didokumentasikan dalam file setup.py ... Anda tidak akan dapat menjalankan file setup.py untuk membaca dependensi yang didokumentasikan (seperti jika mereka ditentukan dalam list di suatu tempat dalam file).
Ini adalah masalah asli pyproject.toml dimaksudkan untuk dipecahkan.
# pyproject.toml
[ build-system ]
# Minimum requirements for the build system to execute.
requires = [ " setuptools>=62.0.0 " , " wheel " ] pyproject.toml duduk berdekatan dengan setup.py di pohon file
build CLI Tool ( pip install build ) adalah proyek khusus oleh Python Packaging Authority (PYPA) yang
[build-system] di pyproject.toml ,pip install build
# both setup.py and pypproject.toml should be together, ideally in the root directory
# python -m build --sdist --wheel path/to/dir/with/setup.py/and/pyproject.toml
python -m build --sdist --wheel . setup.py ke file konfigurasi setup.cfgBergerak dari
# setup.py
from pathlib import Path
from setuptools import find_packages , setup
import wheel
# Function to read the contents of README.md
def read_file ( filename : str ) -> str :
filepath = Path ( __file__ ). resolve (). parent / filename
with open ( filepath , encoding = "utf-8" ) as file :
return file . read ()
setup (
name = "packaging-demo" ,
version = "0.0.0" ,
packages = find_packages (),
# package meta-data
author = "Amit Vikram Raj" ,
author_email = "[email protected]" ,
description = "Demo for Python Packaging" ,
license = "MIT" ,
# Set the long description from README.md
long_description = read_file ( "README.md" ),
long_description_content_type = "text/markdown" ,
# install requires: libraries that are needed for the package to work
install_requires = [
"numpy" , # our package depends on numpy
],
# setup requires: the libraries that are needed to setup/build
# the package distribution
# setup_requires=[
# "wheel", # to build the binary distribution we need wheel package
# ],
)KE
# setup.py
from setuptools import setup
# Now setup.py takes it's configurations from setup.cfg file
setup () # setup.cfg
[metadata]
name = packaging-demo
version = attr: packaging_demo.VERSION
author = Amit Vikram Raj
author_email = [email protected]
description = Demo for Python Packaging
long_description = file: README.md
keywords = one, two
license = MIT
classifiers =
Framework :: Django
Programming Language :: Python :: 3
[options]
zip_safe = False
include_package_data = True
# same as find_packages() in setup()
packages = find:
python_requires = >=3.8
install_requires =
numpy
importlib-metadata ; python_version<"3.10"Pengaturan tambahan juga diteruskan ke file
pyproject.toml. Di sini kami telah menentukanbuild-systemyang mirip dengansetup_requiresdisetup.py
# pyproject.toml
[ build-system ]
# Minimum requirements for the build system to execute
requires = [ " setuptools " , " wheel " , " numpy<1.24.3 " ]
# Adding ruff.toml to pyproject.toml
[ tool . ruff ]
line-length = 99
[ tool . ruff . lint ]
# 1. Enable flake8-bugbear (`B`) rules, in addition to the defaults.
select = [ " E " , " F " , " B " , " ERA " ]
# 2. Avoid enforcing line-length violations (`E501`)
ignore = [ " E501 " ]
# 3. Avoid trying to fix flake8-bugbear (`B`) violations.
unfixable = [ " B " ]
# 4. Ignore `E402` (import violations) in all `__init__.py` files, and in select subdirectories.
[ tool . ruff . lint . per-file-ignores ]
"__init__.py" = [ " E402 " ]
"**/{tests,docs,tools}/*" = [ " E402 " ]
# copying isort configurations from .isort.cfg to pyproject.toml
[ tool . isort ]
profile = " black "
multi_line_output = " VERTICAL_HANGING_INDENT "
force_grid_wrap = 2
line_length = 99
# copying balck config from .black.toml to pyproject.toml
[ tool . black ]
line-length = 99
exclude = " .venv "
# copying flake8 config from .flake8 to pyproject.toml
[ tool . flake8 ]
docstring-convention = " all "
extend-ignore = [ " D107 " , " D212 " , " E501 " , " W503 " , " W605 " , " D203 " , " D100 " ,
" E305 " , " E701 " , " DAR101 " , " DAR201 " ]
exclude = [ " .venv " ]
max-line-length = 99
# radon
radon-max-cc = 10
# copying pylint config from .pylintrc to pyproject.toml
[ tool . pylint . "messages control" ]
disable = [
" line-too-long " ,
" trailing-whitespace " ,
" missing-function-docstring " ,
" consider-using-f-string " ,
" import-error " ,
" too-few-public-methods " ,
" redefined-outer-name " ,
] Kami telah memperlakukan setup.py sebagai file konfigurasi yang dimuliakan, tidak benar -benar memanfaatkan fakta bahwa itu adalah file python dengan menambahkan logika ke dalamnya.
Ini lebih umum daripada tidak. Juga, telah ada pergeseran umum dari menggunakan python untuk file konfigurasi karena melakukannya menambahkan kompleksitas untuk menggunakan file konfigurasi (seperti harus menginstal perpustakaan untuk menjalankan file konfigurasi).
setup.cfg adalah file pendamping untuk setup.py yang memungkinkan kami untuk menentukan konfigurasi paket kami dalam file teks statis - khususnya file format INI.
Nilai apa pun yang tidak secara langsung kami lewati sebagai argumen untuk diatur () akan dicari oleh doa setup () dalam file setup.cfg, yang dimaksudkan untuk duduk berdekatan untuk setup.py di pohon file jika digunakan.
Sekarang kami mengumpulkan banyak file!
setup.pysetup.cfgpyproject.tomlREADME.md.pylintrc , .flake8 , .blackrc , ruff.toml , .mypy , pre-commit-config.yaml , dll.CHANGELOG atau CHANGELOG.mdVERSION atau version.txt Ternyata hampir semua file ini dapat diganti dengan pyproject.toml . Hampir setiap alat kualitas linting / kode mendukung parsing bagian yang pyproject.toml [tool.<name>] [tool.black] .
Dokumen dari masing -masing alat harus memberi tahu Anda cara mencapai ini.
Di atas yang ditampilkan adalah pyproject.toml dengan konfigurasi untuk banyak alat serat yang telah kami gunakan dalam kursus.
Bisakah
setup.cfgdansetup.pyjuga diganti?
setup.cfg ke pyproject.tomlDari
setup.cfg
# setup.cfg
[metadata]
name = packaging-demo
version = attr: packaging_demo.VERSION
author = Amit Vikram Raj
author_email = [email protected]
description = Demo for Python Packaging
long_description = file: README.md
keywords = one, two
license = MIT
classifiers =
Programming Language :: Python :: 3
[options]
zip_safe = False
include_package_data = True
# same as find_packages() in setup()
packages = find:
python_requires = >=3.8
install_requires =
numpy
importlib-metadata ; python_version<"3.10"KE
# pyproject.toml
[ build-system ]
# Minimum requirements for the build system to execute
requires = [ " setuptools>=61.0.0 " , " wheel " ]
# Adding these from setup.cfg in pyproject.toml file
[ project ]
name = " packaging-demo "
authors = [{ name = " Amit Vikram Raj " , email = " [email protected] " }]
description = " Demo for Python Packaging "
readme = " README.md "
requires-python = " >=3.8 "
keywords = [ " one " , " two " ]
license = { text = " MIT " }
classifiers = [ " Programming Language :: Python :: 3 " ]
dependencies = [ " numpy " , ' importlib-metadata; python_version<"3.10" ' ]
dynamic = [ " version " ]
# version = "0.0.3"
# https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html#dynamic-metadata
[ tool . setuptools . dynamic ]
# every while making changes in package, you can change the verison in one of these files
# version = {attr = "packaging_demo.VERSION"} # version read by 'packaging_demo/__init__.py' file
version = { file = [ " version.txt " ]} # version read by 'version.txt' file in root folder
python -m build --sdist --wheel .- Berjalan dengan sempurna, kami menyingkirkan file konfigurasi lain (setup.cfg)
setup.py dengan build-backend Pep 517 menambahkan argumen build-backend ke pyproject.toml like so:
[ build-system ]
# Defined by PEP 518:
requires = [ " flit " ]
# Defined by this PEP:
build-backend = " flit.api:main " # The above toml config is equivalent to
import flit . api
backend = flit . api . main build-backend mendefinisikan titik masuk (modul Python yang dapat dieksekusi dalam hal ini) yang digunakan CLI build untuk benar-benar melakukan pekerjaan parsing pyproject.toml dan membangun roda dan sdist.
Ini berarti Anda dapat mengimplementasikan backend build Anda sendiri hari ini dengan menulis program yang melakukan itu, dan Anda dapat menggunakannya dengan menambahkan paket Anda ke requires = [...] dan menentukan titik entri di build-backend = ...
Jika Anda tidak menentukan build-backend di pyproject.toml , setuptools diasumsikan dan paket akan menjadi sangat baik.
setup.py dan menjalankan python -m build --sdist --wheel . Ini berjalan dengan sempurna tanpa itu karena nilai default build-system ditetapkan sebagai build-backend = "setuptools.build_meta" di build cli yang membangun paket kami. Tetapi Anda masih dapat secara eksplisit menyatakan setuptools sebagai backend build Anda seperti ini
# pyproject.toml
...
[ build-system ]
requires = [ " setuptools>=61.0.0 " , " wheel " ]
build-backend = " setuptools.build_meta "
... Setiap backend build biasanya memperluas file pyproject.toml dengan opsi konfigurasi sendiri. Misalnya,
# pyproject.toml
...
[ tool . setuptools . package-data ]
package_demo = [ " *.json " ]
[ tool . setuptools . dynamic ]
version = { file = " version.txt " }
long_description = { file = " README.md " }
... Jika Anda memilih untuk menggunakan setuptools di proyek Anda, Anda dapat menambahkan bagian ini ke pyproject.toml . Anda dapat membaca lebih lanjut tentang ini di dokumentasi setuptools
Sering bermanfaat untuk memasukkan file non-python seperti file data atau file biner di dalam paket Anda karena seringkali bergantung pada kode python Anda pada file non-python ini.
Dan kemudian kami melihat bahwa jika kami akan memasukkan file -file itu, kami perlu membuat file -file itu berakhir di dalam folder paket kami karena itu adalah folder paket kami yang berakhir di dalam lingkungan virtual pengguna kami saat instalasi.
Kami juga melihat bahwa secara default, semua file non-Python tidak berhasil masuk ke folder lingkungan virtual terakhir. Artinya, jangan benar -benar masuk ke folder paket kami selama prosedur build.
Jadi, bagaimana kami memastikan bahwa file -file ini berakhir di roda/Dist Build dari paket kami? Misalnya di sini kami demo dengan file cities.json yang kami inginkan dalam paket kami seperti yang digunakan oleh file states_info.py .
Dokumen
setuptoolsresmi untuk dukungan data
# pyprject.toml
[ tool . setuptools ]
# ...
# By default, include-package-data is true in pyproject.toml, so you do
# NOT have to specify this line.
include-package-data = true Jadi, setuptools secara default memiliki ini include-package-data yang diatur ke true seperti yang ditunjukkan dalam dokumen resmi tetapi kami perlu membuat MANIFEST.in file tambahan.
IMP: Ini mengimpor semua folder di direktori paket harus memiliki
__init__.pyfile yang menginap direktori data yang ingin kami sertakan karena proses penilaianfind_packages()yang tidak akan dimasukkan ke dalam file yang memiliki file__init__.pydi dalamnya.
# MANIFEST.in
include packaging_demo/*.json
include packaging_demo/my_folder/*.json
OR
Recursive include all json files in the package directory
recursive-include packaging_demo/ *.json
Dokumen tentang Mengkonfigurasi File Manifest.in
MANIFEST.in Dari setuptools docs kami dapat menambahkan ini di file pyproject.toml kami:
# this is by default true so no need to explicitly add it
# but as mentioned in the docs, it is false for other methods like setup.py or setup.cfg
[ tool . setuptools ]
include-package-data = true
# add the data here, it's finding the files recursively
[ tool . setuptools . package-data ]
package_demo = [ " *.json " ]build-backend lainnya dari setuptools Selain setuptools kita dapat menggunakan sistem backend build ini. Titik yang perlu diperhatikan adalah ketika menggunakan sistem lain pyproject.toml cofiguration harus mengikuti standerd mereka.
Menetas
[ build-system ]
requires = [ " hatchling " ]
build-backend = " hatchling.build "Puisi
[ build-system ]
requires = [ " poetry-core>=1.0.0 " ]
build-backend = " poetry.core.masonry.api " Mendokumentasikan versi yang tepat dari ketergantungan kita dan ketergantungannya dan sebagainya.
Dianjurkan untuk memiliki jumlah ketergantungan sesedikit yang terkait dengan paket kami, karena dapat menyebabkan neraka ketergantungan, atau konflik ketergantungan dengan paket lain seperti yang dijelaskan dalam kuliah.
Semakin kompleks pohon ketergantungan lebih tinggi peluang konflik dengan versi perpustakaan lain di masa depan.
Analisis Grafik Ketergantungan oleh Eric
Menjaga versi dependensi dan versi Python disarankan untuk tujuan pemecahan masalah:
pip freeze > requirements.txt pip install pipdeptree graphviz
sudo apt-get install graphviz
# generate the dependency graph
pipdeptree -p packaging-demo --graph-output png > dependency-graph.png[ project . optional-dependencies ]
dev = [ " ruff " , " mypy " , " black " ] # installing our package with optional dependencies
pip install ' .[dev] ' [ project . optional-dependencies ]
# for developement
dev = [ " ruff " , " mypy " , " black " ]
# plugin based architecture
colors = [ " rich " ] # plugin based installation
pip install ' .[colors] '
# here we demo with rich library, if user wants the output to be
# colorized then they can install our package like this.
# we can add multiple optional dependencies like:
pip install ' .[colors, dev] ' [ project . optional-dependencies ]
# for developement
dev = [ " ruff " , " mypy " , " black " ]
# plugin based architecture
colors = [ " rich " ]
# install all dependencies
all = [ " packaging-demo[dev, colors] " ] # Installing all dependencies all at once
pip install ' .[all] ' Kami dapat menggunakan Snyk untuk memeriksa seberapa stabil, didukung dengan baik, jika ada masalah keamanan, dll. Ada untuk dependensi yang akan kami gunakan untuk paket kami dan kemudian mengambil keputusan untuk menggunakannya dalam proyek kami.
Untuk mendapatkan paket kami ke PYPI [Python Packaging Index], sebagaimana dinyatakan dalam panduan resmi, kami menggunakan twine CLI Tool.
pip install twine
twine upload --helpHasilkan Token API untuk Tes PYPI atau PYPI Prod
Bangun Paket Python Anda: python -m build --sdist --wheel "${PACKAGE_DIR}" , di sini kami sedang membangun sdist dan roda, seperti yang disarankan.
Jalankan Alat Twine: twine upload --repository testpypi ./dist/* , menaikkan ke test-pypi
CMake dan Makefile
sudo apt-get install makeTugas
justfile
Pyinvoke
Dev
$ rightArrow $ QA/pementasan$ rightArrow $ Melecut
# .github/workflows/publish.yaml
name : Build, Test, and Publish
# triggers: whenever there is new changes pulled/pushed on this
# repo under given conditions, run the below jobs
on :
pull_request :
types : [opened, synchronize]
push :
branches :
- main
# Manually trigger a workflow
# https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch
workflow_dispatch :
jobs :
build-test-and-publish :
runs-on : ubuntu-latest
steps :
# github actions checksout, clones our repo, and checks out the branch we're working in
- uses : actions/checkout@v3
with :
# Number of commits to fetch. 0 indicates all history for all branches and tags
# fetching all tags so to aviod duplicate version tagging in 'Tag with the Release Version'
fetch-depth : 0
- name : Set up Python 3.8
uses : actions/setup-python@v3
with :
python-version : 3.8
# tagging the release version to avoid duplicate releases
- name : Tag with the Release Version
run : |
git tag $(cat version.txt)
- name : Install Python Dependencies
run : |
/bin/bash -x run.sh install
- name : Lint, Format, and Other Static Code Quality Check
run : |
/bin/bash -x run.sh lint:ci
- name : Build Python Package
run : |
/bin/bash -x run.sh build
- name : Publish to Test PyPI
# setting -x in below publish:test will not leak any secrets as they are masked in github
if : ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
run : |
/bin/bash -x run.sh publish:test
env :
TEST_PYPI_TOKEN : ${{ secrets.TEST_PYPI_TOKEN }}
- name : Publish to Prod PyPI
if : ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
run : |
/bin/bash -x run.sh publish:prod
env :
PROD_PYPI_TOKEN : ${{ secrets.PROD_PYPI_TOKEN }}
- name : Push Tags
if : ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }}
run : |
git push origin --tagsPersyaratan penguncian
Caching ketergantungan
Setiap kali tindakan GitHub dieksekusi di GitHub CI, setiap kali dijalankan pada wadah segar. Dengan demikian, setiap kali kita harus mengunduh dan menginstal ulang dependensi dari PIP lagi dan lagi; Yang tidak bagus karena tidak efisien dan memperlambat alur kerja kita.
Dengan demikian kami ingin menginstal semua dependensi ketika alur kerja berjalan terlebih dahulu dan menggunakannya setiap kali worflow baru dijalankan.
Tindakan GitHub memberikan fungsionalitas ini dengan caching dependensi, ia menyimpan dependensi yang diinstal ( ~/.cache/pip ) dan mengunduhnya setiap kali alur kerja baru dijalankan. Dokumen
- uses : actions/cache@v3
with :
path : ~/.cache/pip
key : ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
restore-keys : |
${{ runner.os }}-pip-setup-python GitHub steps :
- uses : actions/checkout@v4
- uses : actions/setup-python@v5
with :
python-version : ' 3.9 '
cache : ' pip ' # caching pip dependencies
- run : pip install -r requirements.txtParalelisasi
# See .github/workflows/publish.yaml
jobs :
check-verison-txt :
...
lint-format-and-static-code-checks :
....
build-wheel-and-sdist :
...
publish :
needs :
- check-verison-txt
- lint-format-and-static-code-checks
- build-wheel-and-sdist
...
