python packaging
1.0.0
PYTHONPATH 변수공식 파이썬 포장 가이드
Python의 모듈은 Python 코드가 포함 된 단일 파일 ( .py 확장자 포함)입니다. 일반적으로 다른 Python 코드에서 사용할 수있는 클래스, 기능 및 변수로 구성됩니다. 모듈은 코드를 논리 단위로 구성하고 코드 재사용성을 용이하게하는 데 사용됩니다.
예를 들어, 추가, 뺄셈, 곱셈 등과 같은 수학적 작업을 수행하는 기능이 포함 된 math_operations.py 라는 모듈을 고려하십시오. 다른 Python 스크립트에서 이러한 기능을 가져오고 사용할 수 있습니다.
# math_operations.py
def add ( x , y ):
return x + y
def subtract ( x , y ):
return x - y Python의 패키지 는 디렉토리로 그룹화 된 모듈 모듈 모음입니다. 패키지는 일반적으로 __init__.py 파일 (비어있을 수 있음)과 하나 이상의 Python 모듈이 포함 된 디렉토리로 표시됩니다. __init__.py 파일은 디렉토리가 패키지로 취급되어야 함을 Python에 나타냅니다.
예를 들어, my_package 라는 패키지를 고려하십시오.
my_package/
├── __init__.py
├── module1.py
└── module2.py
여기, my_package 는 module1.py 및 module2.py 포함하는 패키지로, dot termation ( my_package.module1 , my_package.module2 )을 사용하여 가져올 수 있습니다.
Python의 하위 패키지는 다른 패키지 내에 중첩 된 패키지입니다. 즉, 패키지에는 모듈뿐만 아니라 다른 패키지가 포함될 수 있습니다. 서브 패키지는 디렉토리를 구성하고 __init__.py 파일을 적절하게 추가하여 패키지 구조를 정의함으로써 만들어집니다.
예를 들어:
my_parent_package/
├── __init__.py
└── my_sub_package/
├── __init__.py
├── module3.py
└── module4.py
이 구조에서 my_sub_package my_parent_package 의 하위 패키지이며 자체 모듈 ( module3.py , module4.py )을 포함 할 수 있습니다. 하위 패키지는 DOT 표기법 ( my_parent_package.my_sub_package.module3 )을 사용하여 가져올 수 있습니다.
Python의 배포 패키지 (또는 간단히 배포 )는 설치할 수있는 패키지 코드 및 리소스의 패키지 모음을 나타냅니다. 일반적으로 모듈, 패키지, 데이터 파일, 구성 파일 및 특정 목적 (예 : 라이브러리 또는 응용 프로그램)에 필요한 기타 리소스가 포함됩니다.
배포 패키지는 종종 pip 와 같은 Python 패키지 관리자를 사용하여 배포 및 설치되며 다른 개발자가 쉽게 배포하고 설치하기 위해 PYPI (Python Package Index)와 같은 패키지 리포지토리에 업로드 할 수 있습니다.
예를 들어, 인기있는 분배 패키지에는 numpy , fast-api , pandas 등이 포함되어 있으며 pip 사용하여 설치하고 Python 프로젝트에 사용할 수있는 기능을 제공합니다.
sdist 형식setup.py 구성하십시오python setup.py build sdistpip install ./dist/<package_name>.tar.gz 패키지를 설치합니다pip list 사용하여 패키지가 설치되어 있는지 확인하십시오. 패키지에서 변경이 이루어지면 pip install . 최신 패키지를 즉시 구축하고 설치합니다.
또는 단순히 편집 가능성을 사용하여 항상 패키지 EvreryTime 패키지를 재건 할 필요는 없습니다. 새로운 변경 사항이 있습니다.
pip install --editable . sdist 는 소스 배포 .tar 짧습니다. 이는 배포 패키지에는 소스 코드의 하위 집합 만 포함되어 있다는 것입니다.
"소스 배포"는 본질적으로 소스 코드를 포함하는 ZIPPER 폴더입니다.
wheel 형식 소스 배포 ( sdist ) :
*.py ), 구성 파일 및 기타 프로젝트 관련 자산이 포함됩니다.python setup.py sdist 사용하여 만들 수 있습니다. 바퀴 ( bdist_wheel ) :
sdist 와 비교하여보다 고급 분포 형식..whl 확장자가있는 지퍼 파일을 나타냅니다.python setup.py bdist_wheel 사용하여 생성되었습니다. 더 빠른 설치 :
*.whl )에서 설치하는 것은 일반적으로 소스 배포 ( *.tar.gz )에서 설치하는 것보다 빠릅니다.사용자를위한 사용 편의성 :
sdist 및 bdist_wheel 구축sdist 및 bdist_wheel 모두 구축하고 게시하는 것이 좋습니다.python setup.py sdist bdist_wheel컴파일 요구 사항 :
불행히도, 컴파일 단계가 필요한 경우 모든 운영 체제의 건물 바퀴가 어려워 지므로 일부 OSS 관리자는 단일 OS 용 바퀴 만 구축합니다.
pip 실제로 SDIST를 다운로드 한 직후 시스템 에서 setup.py (또는 동등한 파일)를 실행합니다.휠을 구축하려면 컴파일 코드가 필요할 수 있습니다
gcc 소스 코드가 C 인 경우 다른 언어에는 자체 컴파일러가 필요합니다. 사용자는 기기 또는 pip install ... 단순히 실패합니다. numpy , pandas , scipy , pytorch , tensorflow 등을 설치할 때 발생할 수 있습니다. setup.py 임의 코드가 포함될 수 있습니다. 이것은 매우 안전하지 않습니다. setup.py 악의적 인 코드가 포함될 수 있습니다.
종속성 관리 :
gcc 등)을 설치해야 할 수도 있습니다.보안 문제 :
setup.py 사용하는 것은 임의 코드를 실행하므로 불안할 수 있습니다.wheel 파일의 이름 지정 체계휠 파일 이름은 하이픈으로 분리 된 부품으로 분해됩니다.
{dist}-{version}(-{build})?-{python}-{abi}-{platform}.whl {brackets} 의 각 섹션은 태그 또는 휠 이름의 구성 요소입니다. 휠이 포함 된 내용과 휠이 작동하거나 작동하지 않는 위치에 대한 의미를 전달합니다.
예를 들어 : dist/packaging-0.0.0-py3-none-any.whl
packaging 패키지 이름입니다0.0.0 은 Verison 번호입니다py3 Python3의 빌드를 나타냅니다abi 태그. ABI는 애플리케이션 바이너리 인터페이스를 나타냅니다.any 된 것입니다.기타 예 :
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.whl그 이유는 휠 파일에는 패키지를 빠르게 설치하는 데 도움이되는 사전 완료 된 이진 코드가 포함되어 있기 때문입니다.
패키지 유지 보수 :
sdist 및 bdist_wheel 배포판을 모두 제공하기 위해 노력해야합니다.사용자 경험을 고려하십시오 :
pyproject.toml build"Build Dependencies"는 분배 패키지를 SDIST 또는 휠에 구축하기 위해 시스템에 설치 해야하는 모든 것입니다.
예를 들어, python setup.py bdist_wheel 실행하려면 pip install wheel 해야했습니다. 따라서 wheel 빌드 휠의 빌드 의존성입니다.
setup.py 파일이 복잡해 질 수 있습니다.
복잡한 빌드 프로세스를 수용하기 위해 외부 라이브러리를 pip install ... 하고 setup.py 파일로 가져와야 할 수도 있습니다.
이 강의는 복잡한 setup.py 파일을 갖춘 패키지의 예로 pytorch 와 airflow 보여줍니다.
어떻게 든 setup.py 이외 의 빌드 종속성을 문서화 할 수 있어야합니다.
setup.py 파일에 문서화 된 경우… setup.py 파일을 실행하여 문서화 된 종속성을 읽을 수 없습니다 (파일 어딘가에 list 에 지정된 경우).
이것은 pyproject.toml 해결하기위한 원래의 문제입니다.
# pyproject.toml
[ build-system ]
# Minimum requirements for the build system to execute.
requires = [ " setuptools>=62.0.0 " , " wheel " ] pyproject.toml 파일 트리의 setup.py 에 인접 해 있습니다
build CLI 도구 ( pip install build )는 Python Packaging Authority (PYPA)의 특별 프로젝트입니다.
pyproject.toml 에서 [build-system] 테이블을 읽습니다.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 에서 setup.cfg 구성 파일로 이동합니다에서 움직입니다
# 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
# ],
)에게
# 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"또한 추가 설정은
pyproject.toml파일로 전달됩니다. 여기서 우리는setup.py의setup_requires와 유사한build-system지정했습니다.
# 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 " ,
] 우리는 setup.py 영광스러운 구성 파일로 취급했으며, 실제로 논리를 추가하여 Python 파일이라는 사실을 활용하지는 않습니다.
이것은 그렇지 않은 것보다 더 일반적입니다. 또한 구성 파일에 Python을 사용하는 것보다 일반적인 변화가 있었기 때문에 구성 파일을 사용하는 데 복잡성이 추가되므로 구성 파일을 실행하기 위해 라이브러리를 설치해야 함).
setup.cfg 는 정적 텍스트 파일, 특히 INI 형식 파일에서 패키지 구성을 정의 할 수있는 setup.py 의 동반자 파일입니다.
setup.cfg 파일의 setup () 호출에 의해 setup ()로 직접 전달되지 않는 값은 사용하면 파일 트리의 setup.py에 인접 해 있어야합니다.
이제 우리는 많은 파일을 축적하고 있습니다!
setup.pysetup.cfgpyproject.tomlREADME.md.pylintrc , .flake8 , .blackrc , ruff.toml , .mypy , pre-commit-config.yaml 등CHANGELOG 또는 CHANGELOG.mdVERSION 또는 version.txt 이 파일의 거의 모든 파일을 pyproject.toml 로 대체 할 수 있습니다. 거의 모든 Linting / Code 품질 도구 [tool.black] [tool.<name>] pyproject.toml 섹션을 구문 분석하는 것을 지원합니다.
각 개별 도구의 문서는이를 달성하는 방법을 알려야합니다.
위에 표시된 위는 코스에서 사용한 많은 라인 툴에 대한 구성이있는 pyproject.toml 입니다.
setup.cfg및setup.py도 교체 할 수 있습니까?
setup.cfg pyproject.toml 로 이동합니다
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"에게
# 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 .- 완벽하게 실행되면 다른 구성 파일 (setup.cfg)을 제거했습니다.
setup.py build-backend 로 교체합니다 Pep 517은 pyproject.toml 에 build-backend 인수를 추가했습니다.
[ 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 build CLI가 실제로 pyproject.toml 구문 분석하고 휠과 SDIST를 구축하는 작업을 수행하는 데 사용하는 EntryPoint (이 경우 실행 파이썬 모듈)를 정의합니다.
즉, 오늘 자신의 Build 백엔드를 구현할 수 있으며,이를 수행하는 프로그램을 작성하여 requires = [...] 를 추가하고 EntryPoint를 build-backend = ... 에 지정하여 사용할 수 있습니다.
pyproject.toml 에 build-backend 지정하지 않으면 Setupools가 가정되며 패키지는 Bulit가 전형적으로 잘됩니다.
setup.py 제거하고 python -m build --sdist --wheel . build-system build-backend = "setuptools.build_meta" 로 설정되기 때문에 패키지를 빌드하는 build 블리로 설정되므로 완벽하게 실행됩니다. 그러나 당신은 여전히 당신의 build backend로 setuptools 명시 적으로 선언 할 수 있습니다.
# pyproject.toml
...
[ build-system ]
requires = [ " setuptools>=61.0.0 " , " wheel " ]
build-backend = " setuptools.build_meta "
... 각 빌드 백엔드는 일반적으로 자체 구성 옵션으로 pyproject.toml 파일을 확장합니다. 예를 들어,
# pyproject.toml
...
[ tool . setuptools . package-data ]
package_demo = [ " *.json " ]
[ tool . setuptools . dynamic ]
version = { file = " version.txt " }
long_description = { file = " README.md " }
... 프로젝트에서 setuptools 사용하기로 선택한 경우이 섹션을 pyproject.toml 에 추가 할 수 있습니다. setuptools 문서에서 이것에 대한 자세한 내용을 읽을 수 있습니다.
파이썬 코드가 이러한 비 파이썬 파일에 의존하기 때문에 패키지 내부에 데이터 파일이나 이진 파일과 같은 비 파이썬 파일을 포함하는 것이 좋습니다.
그런 다음 해당 파일을 포함하려면 해당 파일이 패키지 폴더 내부에있는 파일이 설치시 사용자 가상 환경 내부에있는 패키지 폴더이기 때문에 파일이 패키지 폴더 내부로 끝나도록해야한다는 것을 알았습니다.
또한 기본적으로 모든 비 파이썬 파일이 해당 최종 가상 환경 폴더로 만들지 않는다는 것을 알았습니다. 즉, 빌드 절차 중에 실제로 패키지 폴더로 만들지 마십시오.
그렇다면이 파일이 패키지의 휠/디스크 빌드에서 어떻게 끝나도록하려면 어떻게해야합니까? 예를 들어 여기서는 cities.json 파일 states_info.py 사용하여 Pac
데이터 지원을위한 공식
setuptools문서
# 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 따라서 SetUptools에는 기본적으로 SetUptools에는 공식 문서에 표시된대로 include-package-data 값이 true 로 설정되어 있지만 추가 파일 MANIFEST.in 작성하고 Root Dir에있는 패키지에 포함하려는 데이터를 지정해야합니다.
IMP : 패키지 디렉토리의 모든 폴더를 가져옵니다.
__init__.py파일에는 setuptools가하는find_packages()Recusrive 프로세스가__init__.py파일이있는 fo; ders로 들어 가지 않기 때문에 포함하려는 데이터 디렉토리를 포함해야합니다.
# 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
파일을 구성하는 문서
MANIFEST.in 파일을 사용하지 않고 setuptools 문서에서 pyproject.toml 파일에 이것을 추가 할 수 있습니다.
# 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 " ]setuptools 외에 다른 build-backend 시스템 setuptools 외에이 빌드 백엔드 시스템을 사용할 수 있습니다. 주목할만한 점은 다른 시스템을 사용할 때 pyproject.toml cofiguration이 그들의 스탠드를 따라야한다는 것입니다.
해치
[ build-system ]
requires = [ " hatchling " ]
build-backend = " hatchling.build "시
[ build-system ]
requires = [ " poetry-core>=1.0.0 " ]
build-backend = " poetry.core.masonry.api " 우리의 종속성과 그 종속성의 정확한 버전을 문서화합니다.
의존성 지옥으로 이어질 수 있거나 강의에서 설명 된 바와 같이 다른 패키지와 의존성 충돌로 이어질 수 있으므로 패키지와 관련된 의존성이 적은 수준을 갖는 것이 좋습니다.
의존성 트리가 더 복잡할수록 미래 버전의 다른 라이브러리와 충돌 할 가능성이 높아집니다.
Eric의 종속성 그래프 분석
고정 버전의 종속성 및 파이썬 버전을 유지하는 것이 좋습니다.
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] ' 우리는 Snyk를 사용하여 보안 문제 등이 패키지에 사용할 의존성에 대한 보안 문제 등이 있는지 확인한 다음 프로젝트에서이를 사용하기로 결정할 수 있습니다.
공식 안내서에 명시된 바와 같이 패키지를 PYPI [Python Packaging Index]로 Pusblish로 만들기 위해 twine CLI 도구를 사용합니다.
pip install twine
twine upload --helpPYPI 테스트 또는 PYPI Prod 용 API 토큰을 생성합니다
파이썬 패키지를 빌드 : python -m build --sdist --wheel "${PACKAGE_DIR}" , 여기에서는 SDIST와 휠을 모두 구축합니다.
꼬기 도구 실행 : twine upload --repository testpypi ./dist/* , test-pypi로 향상
CMake 및 Makefile
sudo apt-get install make작업 파일
justfile
Pyinvoke
데브
$ rightarrow $ QA/준비$ rightarrow $ 찌르다
# .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 --tags잠금 요구 사항
의존성 캐싱
Github 동작이 Github CI에서 실행될 때마다 신선한 컨테이너에서 실행할 때마다. 따라서 매번 PIP에서 종속성을 다운로드하여 다시 설치해야합니다. 그것은 비효율적이고 우리의 워크 플로를 느리게하기 때문에 좋지 않습니다.
따라서 워크 플로가 먼저 실행될 때 모든 종속성을 설치하고 새 벌어가 실행될 때마다 사용하려고합니다.
GitHub 작업은 종속성을 캐싱 하여이 기능을 제공하고 설치된 종속성 ( ~/.cache/pip )을 저장하고 새 워크 플로가 실행될 때마다 다운로드합니다. 문서
- uses : actions/cache@v3
with :
path : ~/.cache/pip
key : ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
restore-keys : |
${{ runner.os }}-pip-setup-python Github 동작을 사용한 PIP 의존성 캐싱 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.txt병렬화
# 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
...
