pip tools

pip-tools = pip-compile + pip-sync

ชุดเครื่องมือบรรทัดคำสั่งที่จะช่วยให้คุณรักษาแพ็คเกจที่ใช้ pip ของคุณให้ใหม่อยู่เสมอ แม้ว่าคุณจะปักหมุดไว้แล้วก็ตาม คุณปักหมุดพวกเขาใช่ไหม? (ในการสร้างแอปพลิเคชัน Python และการขึ้นต่อกันในการใช้งานจริง คุณต้องแน่ใจว่าบิวด์ของคุณสามารถคาดเดาได้และกำหนดได้)

การติดตั้ง

เช่นเดียวกับ pip จะต้องติดตั้ง pip-tools ในแต่ละสภาพแวดล้อมเสมือนของโปรเจ็กต์ของคุณ:

$ source /path/to/venv/bin/activate
(venv) $ python -m pip install pip-tools

หมายเหตุ : คำสั่งตัวอย่างที่เหลือทั้งหมดถือว่าคุณได้เปิดใช้งานสภาพแวดล้อมเสมือนของโปรเจ็กต์แล้ว

ตัวอย่างการใช้งาน pip-compile

คำสั่ง pip-compile ช่วยให้คุณรวบรวมไฟล์ requirements.txt จากการขึ้นต่อกันของคุณ โดยระบุใน pyproject.toml , setup.cfg , setup.py หรือ requirements.in

รันด้วย pip-compile หรือ python -m piptools compile (หรือ pipx run --spec pip-tools pip-compile หาก pipx ได้รับการติดตั้งด้วยเวอร์ชัน Python ที่เหมาะสม) หากคุณใช้ Python หลายเวอร์ชัน คุณยังสามารถเรียกใช้ py -XY -m piptools compile บน Windows และ pythonX.Y -m piptools compile บนระบบอื่นได้

pip-compile ควรรันจากสภาพแวดล้อมเสมือนเดียวกันกับโปรเจ็กต์ของคุณ ดังนั้นการขึ้นต่อกันแบบมีเงื่อนไขที่ต้องใช้เวอร์ชัน Python เฉพาะหรือเครื่องหมายสภาพแวดล้อมอื่น ๆ ได้รับการแก้ไขโดยสัมพันธ์กับสภาพแวดล้อมของโปรเจ็กต์ของคุณ

หมายเหตุ : หาก pip-compile พบไฟล์ requirements.txt ที่มีอยู่ซึ่งเป็นไปตามการขึ้นต่อกัน จะไม่มีการเปลี่ยนแปลงใด ๆ แม้ว่าจะมีการอัปเดตก็ตาม หากต้องการคอมไพล์ตั้งแต่เริ่มต้น ให้ลบไฟล์ requirements.txt ที่มีอยู่ออกก่อน หรือดูการอัพเดตข้อกำหนดสำหรับแนวทางอื่น

ข้อกำหนดจาก pyproject.toml

ไฟล์ pyproject.toml เป็นมาตรฐานล่าสุดสำหรับการกำหนดค่าแพ็คเกจและแอปพลิเคชัน และแนะนำสำหรับโปรเจ็กต์ใหม่ pip-compile รองรับทั้งการติดตั้ง project.dependencies และ project.optional-dependencies ของคุณ เนื่องจากนี่เป็นมาตรฐานอย่างเป็นทางการ คุณสามารถใช้ pip-compile เพื่อปักหมุดการขึ้นต่อกันในโปรเจ็กต์ที่ใช้เครื่องมือบรรจุภัณฑ์ที่ยึดตามมาตรฐานสมัยใหม่ เช่น Setuptools, Hatch หรือ flit

สมมติว่าคุณมีแอปพลิเคชัน Python 'foobar' ที่บรรจุแพ็คเกจโดยใช้ Setuptools และคุณต้องการปักหมุดแอปพลิเคชันนั้นสำหรับการผลิต คุณสามารถประกาศข้อมูลเมตาของโครงการเป็น:

[ build-system ]
requires = [ " setuptools " , " setuptools-scm " ]
build-backend = " setuptools.build_meta "

[ project ]
requires-python = " >=3.9 "
name = " foobar "
dynamic = [ " dependencies " , " optional-dependencies " ]

[ tool . setuptools . dynamic ]
dependencies = { file = [ " requirements.in " ] }
optional-dependencies.test = { file = [ " requirements-test.txt " ] }

หากคุณมีแอปพลิเคชัน Django ที่แพ็กเกจโดยใช้ Hatch และคุณต้องการปักหมุดแอปพลิเคชันนั้นสำหรับการผลิต คุณยังต้องการปักหมุดเครื่องมือการพัฒนาของคุณในไฟล์พินแยกต่างหาก คุณประกาศ django เป็นการพึ่งพาและสร้าง dev การพึ่งพาทางเลือกที่มี pytest :

[ build-system ]
requires = [ " hatchling " ]
build-backend = " hatchling.build "

[ project ]
name = " my-cool-django-app "
version = " 42 "
dependencies = [ " django " ]

[ project . optional-dependencies ]
dev = [ " pytest " ]

คุณสามารถสร้างไฟล์พินของคุณได้อย่างง่ายดายดังนี้:

$ pip-compile -o requirements.txt pyproject.toml
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --output-file=requirements.txt pyproject.toml
#
asgiref==3.6.0
    # via django
django==4.1.7
    # via my-cool-django-app (pyproject.toml)
sqlparse==0.4.3
    # via django

$ pip-compile --extra dev -o dev-requirements.txt pyproject.toml
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --extra=dev --output-file=dev-requirements.txt pyproject.toml
#
asgiref==3.6.0
    # via django
attrs==22.2.0
    # via pytest
django==4.1.7
    # via my-cool-django-app (pyproject.toml)
exceptiongroup==1.1.1
    # via pytest
iniconfig==2.0.0
    # via pytest
packaging==23.0
    # via pytest
pluggy==1.0.0
    # via pytest
pytest==7.2.2
    # via my-cool-django-app (pyproject.toml)
sqlparse==0.4.3
    # via django
tomli==2.0.1
    # via pytest

วิธีนี้เหมาะสำหรับทั้งการปักหมุดแอปพลิเคชันของคุณ แต่ยังเพื่อรักษา CI ของแพ็คเกจ Python โอเพ่นซอร์สของคุณให้เสถียรอีกด้วย

ข้อกำหนดจาก setup.py และ setup.cfg

pip-compile ยังรองรับ setup.py - และ setup.cfg โปรเจ็กต์ที่ใช้ setuptools อย่างเต็มรูปแบบ

เพียงกำหนดการขึ้นต่อกันและความพิเศษของคุณตามปกติแล้วรัน pip-compile ดังที่กล่าวข้างต้น

ข้อกำหนดจาก requirements.in

คุณยังสามารถใช้ไฟล์ข้อความธรรมดาตามความต้องการของคุณได้ (เช่น ถ้าคุณไม่ต้องการให้แอปพลิเคชันของคุณเป็นแพ็คเกจ) หากต้องการใช้ไฟล์ requirements.in เพื่อประกาศการพึ่งพา Django:

 # requirements.in
django

ตอนนี้รัน pip-compile requirements.in :

$ pip-compile requirements.in
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile requirements.in
#
asgiref==3.6.0
    # via django
django==4.1.7
    # via -r requirements.in
sqlparse==0.4.3
    # via django

และมันจะสร้าง requirements.txt ของคุณโดยยึดการพึ่งพา Django ทั้งหมด (และการพึ่งพาพื้นฐานทั้งหมด)

(การอัปเดต-ข้อกำหนด)=

กำลังอัปเดตข้อกำหนด

pip-compile สร้างไฟล์ requirements.txt โดยใช้เวอร์ชันล่าสุดที่เป็นไปตามการขึ้นต่อกันที่คุณระบุในไฟล์ที่รองรับ

หาก pip-compile พบไฟล์ requirements.txt ที่มีอยู่ซึ่งเป็นไปตามการขึ้นต่อกัน ก็จะไม่มีการเปลี่ยนแปลงใด ๆ แม้ว่าจะมีการอัปเดตก็ตาม

หากต้องการบังคับให้ pip-compile อัปเดตแพ็กเกจทั้งหมดใน requirements.txt ที่มีอยู่ ให้รัน pip-compile --upgrade

หากต้องการอัปเดตแพ็คเกจเฉพาะเป็นเวอร์ชันล่าสุดหรือเฉพาะให้ใช้แฟล็ก --upgrade-package หรือ -P :

# only update the django package
$ pip-compile --upgrade-package django

# update both the django and requests packages
$ pip-compile --upgrade-package django --upgrade-package requests

# update the django package to the latest, and requests to v2.0.0
$ pip-compile --upgrade-package django --upgrade-package requests==2.0.0

คุณสามารถรวม --upgrade และ --upgrade-package ไว้ในคำสั่งเดียว เพื่อให้มีข้อจำกัดในการอัปเกรดที่อนุญาต ตัวอย่างเช่น หากต้องการอัปเกรดแพ็คเกจทั้งหมดในขณะที่จำกัดคำขอเป็นเวอร์ชันล่าสุดที่น้อยกว่า 3.0:

$ pip-compile --upgrade --upgrade-package ' requests<3.0 '

การใช้แฮช

หากคุณต้องการใช้ โหมดการตรวจสอบแฮช ที่มีใน pip ตั้งแต่เวอร์ชัน 8.0 ข้อเสนอ pip-compile --generate-hashes :

$ pip-compile --generate-hashes requirements.in
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --generate-hashes requirements.in
#
asgiref==3.6.0 
    --hash=sha256:71e68008da809b957b7ee4b43dbccff33d1b23519fb8344e33f049897077afac 
    --hash=sha256:9567dfe7bd8d3c8c892227827c41cce860b368104c3431da67a0c5a65a949506
    # via django
django==4.1.7 
    --hash=sha256:44f714b81c5f190d9d2ddad01a532fe502fa01c4cb8faf1d081f4264ed15dcd8 
    --hash=sha256:f2f431e75adc40039ace496ad3b9f17227022e8b11566f4b363da44c7e44761e
    # via -r requirements.in
sqlparse==0.4.3 
    --hash=sha256:0323c0ec29cd52bceabc1b4d9d579e311f3e4961b98d174201d5622a23b85e34 
    --hash=sha256:69ca804846bb114d2ec380e4360a8a340db83f0ccf3afceeb1404df028f57268
    # via django

ไฟล์เอาท์พุต

หากต้องการส่งออกข้อกำหนดที่ปักหมุดไว้ในชื่อไฟล์อื่นที่ไม่ใช่ requirements.txt ให้ใช้ --output-file สิ่งนี้อาจมีประโยชน์สำหรับการคอมไพล์หลายไฟล์ เช่น ด้วยข้อจำกัดที่แตกต่างกันบน django เพื่อทดสอบไลบรารีที่มีทั้งสองเวอร์ชันโดยใช้ tox:

$ pip-compile --upgrade-package ' django<1.0 ' --output-file requirements-django0x.txt
$ pip-compile --upgrade-package ' django<2.0 ' --output-file requirements-django1x.txt

หรือหากต้องการส่งออกไปยังเอาต์พุตมาตรฐานให้ใช้ --output-file=- :

$ pip-compile --output-file=- > requirements.txt
$ pip-compile - --output-file=- < requirements.in > requirements.txt

ตัวเลือกการส่งต่อไปยัง pip

ค่าสถานะหรืออาร์กิวเมนต์ pip ที่ถูกต้องใด ๆ อาจถูกส่งต่อด้วยตัวเลือก --pip-args ของ pip-compile เช่น

$ pip-compile requirements.in --pip-args " --retries 10 --timeout 30 "

การกำหนดค่า

คุณสามารถกำหนดค่าเริ่มต้นระดับโปรเจ็กต์สำหรับ pip-compile และ pip-sync โดยการเขียนลงในไฟล์การกำหนดค่าในไดเร็กทอรีเดียวกันกับไฟล์อินพุตความต้องการของคุณ (หรือไดเร็กทอรีการทำงานปัจจุบันหากไพพ์อินพุตจาก stdin) ตามค่าเริ่มต้น ทั้ง pip-compile และ pip-sync จะมองหาไฟล์ .pip-tools.toml ก่อน จากนั้นจึงค้นหาใน pyproject.toml ของคุณ คุณยังสามารถระบุไฟล์การกำหนดค่า TOML สำรองด้วยตัวเลือก --config

สามารถระบุค่าคอนฟิกูเรชันทั้งแบบโกลบอลและเฉพาะคำสั่งได้ ตัวอย่างเช่น หากต้องการสร้างแฮช pip ในเอาต์พุตไฟล์ข้อกำหนดที่เป็นผลลัพธ์ คุณสามารถระบุในไฟล์การกำหนดค่าได้:

[ tool . pip-tools ]
generate-hashes = true

ตัวเลือกใน pip-compile และ pip-sync ที่อาจใช้มากกว่าหนึ่งครั้งจะต้องถูกกำหนดเป็นรายการในไฟล์การกำหนดค่า แม้ว่าจะมีเพียงค่าเดียวก็ตาม

pip-tools รองรับค่าเริ่มต้นสำหรับแฟล็กบรรทัดคำสั่งที่ถูกต้องทั้งหมดของคำสั่งย่อย คีย์การกำหนดค่าอาจมีขีดล่างแทนขีดกลาง ดังนั้นจึงสามารถระบุด้านบนในรูปแบบนี้ได้เช่นกัน:

[ tool . pip-tools ]
generate_hashes = true

ค่าเริ่มต้นของการกำหนดค่าเฉพาะสำหรับ pip-compile และ pip-sync สามารถวางไว้ใต้ส่วนที่แยกจากกัน ตัวอย่างเช่น โดยค่าเริ่มต้นให้ดำเนินการ dry-run ด้วย pip-compile :

[ tool . pip-tools . compile ] # "sync" for pip-sync
dry-run = true

ซึ่งจะไม่ส่งผลต่อคำสั่ง pip-sync ซึ่งมีตัวเลือก --dry-run ด้วยเช่นกัน โปรดทราบว่าการตั้งค่าในเครื่องจะมีความสำคัญมากกว่าการตั้งค่าส่วนกลางที่มีชื่อเดียวกัน เมื่อใดก็ตามที่มีการประกาศทั้งสองรายการ ดังนั้นการดำเนินการนี้จะทำให้ pip-compile สร้างแฮชด้วย แต่ยกเลิกการตั้งค่า dry-run ส่วนกลาง:

[ tool . pip-tools ]
generate-hashes = true
dry-run = true

[ tool . pip-tools . compile ]
dry-run = false

คุณอาจล้อมคำสั่ง pip-compile ไว้ในสคริปต์อื่น เพื่อหลีกเลี่ยงไม่ให้ผู้บริโภคสับสนกับสคริปต์ที่คุณกำหนดเอง คุณสามารถแทนที่คำสั่งอัพเดตที่สร้างขึ้นที่ด้านบนของไฟล์ข้อกำหนดโดยตั้งค่าตัวแปรสภาพแวดล้อม CUSTOM_COMPILE_COMMAND

$ CUSTOM_COMPILE_COMMAND= " ./pipcompilewrapper " pip-compile requirements.in
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    ./pipcompilewrapper
#
asgiref==3.6.0
    # via django
django==4.1.7
    # via -r requirements.in
sqlparse==0.4.3
    # via django

ขั้นตอนการทำงานสำหรับข้อกำหนดแบบเลเยอร์

หากคุณมีสภาพแวดล้อมที่แตกต่างกันซึ่งคุณต้องติดตั้งแพ็คเกจที่แตกต่างกันแต่เข้ากันได้ คุณสามารถสร้างไฟล์ข้อกำหนดแบบเลเยอร์และใช้เลเยอร์หนึ่งเพื่อจำกัดอีกเลเยอร์หนึ่งได้

ตัวอย่างเช่น หากคุณมีโปรเจ็กต์ Django ที่คุณต้องการรีลีส 2.1 ใหม่ล่าสุดในการใช้งานจริง และเมื่อกำลังพัฒนาคุณต้องการใช้แถบเครื่องมือดีบัก Django คุณสามารถสร้างไฟล์ *.in สองไฟล์ หนึ่งไฟล์สำหรับแต่ละเลเยอร์:

 # requirements.in
django<2.2

ที่ด้านบนสุดของข้อกำหนดการพัฒนา dev-requirements.in คุณใช้ -c requirements.txt เพื่อจำกัดข้อกำหนด dev ให้กับแพ็คเกจที่เลือกไว้แล้วสำหรับการผลิตใน requirements.txt

 # dev-requirements.in
-c requirements.txt
django-debug-toolbar<2.2

ขั้นแรก ให้คอมไพล์ requirements.txt ตามปกติ:

 $ pip-compile
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile
#
django==2.1.15
    # via -r requirements.in
pytz==2023.3
    # via django

ตอนนี้รวบรวมข้อกำหนดของ dev และไฟล์ requirements.txt ถูกใช้เป็นข้อจำกัด:

$ pip-compile dev-requirements.in
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile dev-requirements.in
#
django==2.1.15
    # via
    #   -c requirements.txt
    #   django-debug-toolbar
django-debug-toolbar==2.1
    # via -r dev-requirements.in
pytz==2023.3
    # via
    #   -c requirements.txt
    #   django
sqlparse==0.4.3
    # via django-debug-toolbar

ดังที่คุณเห็นข้างต้น แม้ว่า Django รุ่น 2.2 จะพร้อมใช้งาน แต่ข้อกำหนดในการพัฒนาจะรวมเฉพาะ Django เวอร์ชัน 2.1 เท่านั้น เนื่องจากถูกจำกัด ขณะนี้ไฟล์ข้อกำหนดที่คอมไพล์แล้วทั้งสองไฟล์สามารถติดตั้งได้อย่างปลอดภัยในสภาพแวดล้อม dev

หากต้องการติดตั้งข้อกำหนดในขั้นตอนการผลิตให้ใช้:

$ pip-sync

คุณสามารถติดตั้งข้อกำหนดในขั้นตอนการพัฒนาได้โดย:

$ pip-sync requirements.txt dev-requirements.txt

บูรณาการการควบคุมเวอร์ชัน

คุณอาจใช้ pip-compile เป็นตะขอสำหรับการคอมมิตล่วงหน้า ดูเอกสารก่อนคอมมิตสำหรับคำแนะนำ ตัวอย่าง .pre-commit-config.yaml :

 repos :
  - repo : https://github.com/jazzband/pip-tools
    rev : 7.4.1
    hooks :
      - id : pip-compile

คุณอาจต้องการปรับแต่ง pip-compile args โดยการกำหนด args และ/หรือ files ตัวอย่างเช่น:

 repos :
  - repo : https://github.com/jazzband/pip-tools
    rev : 7.4.1
    hooks :
      - id : pip-compile
        files : ^requirements/production.(in|txt)$
        args : [--index-url=https://example.com, requirements/production.in]

หากคุณมีไฟล์ข้อกำหนดหลายไฟล์ ตรวจสอบให้แน่ใจว่าคุณสร้างตะขอสำหรับแต่ละไฟล์

 repos :
  - repo : https://github.com/jazzband/pip-tools
    rev : 7.4.1
    hooks :
      - id : pip-compile
        name : pip-compile setup.py
        files : ^(setup.py|requirements.txt)$
      - id : pip-compile
        name : pip-compile requirements-dev.in
        args : [requirements-dev.in]
        files : ^requirements-dev.(in|txt)$
      - id : pip-compile
        name : pip-compile requirements-lint.in
        args : [requirements-lint.in]
        files : ^requirements-lint.(in|txt)$
      - id : pip-compile
        name : pip-compile requirements.in
        args : [requirements.in]
        files : ^requirements.(in|txt)$

ตัวอย่างการใช้งาน pip-sync

เมื่อคุณมี requirements.txt แล้ว คุณสามารถใช้ pip-sync เพื่ออัปเดตสภาพแวดล้อมเสมือนของคุณเพื่อให้สะท้อนถึงสิ่งที่อยู่ในนั้นได้อย่างชัดเจน การดำเนินการนี้จะติดตั้ง/อัปเกรด/ถอนการติดตั้งทุกสิ่งที่จำเป็นเพื่อให้ตรงกับเนื้อหา requirements.txt

รันด้วย pip-sync หรือ python -m piptools sync หากคุณใช้ Python หลายเวอร์ชัน คุณยังสามารถเรียกใช้ py -XY -m piptools sync บน Windows และ pythonX.Y -m piptools sync บนระบบอื่นได้

ต้องติดตั้ง pip-sync และเรียกใช้จากสภาพแวดล้อมเสมือนเดียวกันกับโปรเจ็กต์ของคุณ เพื่อระบุแพ็คเกจที่จะติดตั้งหรืออัปเกรด

ระวัง : pip-sync มีไว้เพื่อใช้เฉพาะกับ requirements.txt ที่สร้างโดย pip-compile เท่านั้น

$ pip-sync
Uninstalling flake8-2.4.1:
    Successfully uninstalled flake8-2.4.1
Collecting click==4.1
    Downloading click-4.1-py2.py3-none-any.whl (62kB)
    100% |................................| 65kB 1.8MB/s
    Found existing installation: click 4.0
    Uninstalling click-4.0:
        Successfully uninstalled click-4.0
Successfully installed click-4.1

หากต้องการซิงค์รายการอ้างอิง *.txt หลายรายการ เพียงส่งรายการเหล่านั้นผ่านอาร์กิวเมนต์บรรทัดคำสั่ง เช่น

$ pip-sync dev-requirements.txt requirements.txt

การส่งผ่านอาร์กิวเมนต์ที่ว่างเปล่าจะทำให้ค่าเริ่มต้นเป็น requirements.txt

ค่าสถานะหรือข้อโต้แย้ง pip install ที่ถูกต้องอาจถูกส่งผ่านด้วยตัวเลือก --pip-args ของ pip-sync เช่น

$ pip-sync requirements.txt --pip-args " --no-cache-dir --no-deps "

หมายเหตุ : pip-sync จะไม่อัปเกรดหรือถอนการติดตั้งเครื่องมือบรรจุภัณฑ์ เช่น setuptools , pip หรือ pip-tools เอง ใช้ python -m pip install --upgrade เพื่ออัพเกรดแพ็คเกจเหล่านั้น

ฉันควรยอมรับ requirements.in และ requirements.txt กับการควบคุมแหล่งที่มาหรือไม่

โดยทั่วไปแล้วใช่ หากคุณต้องการให้มีการติดตั้งสภาพแวดล้อมที่ทำซ้ำได้จากการควบคุมต้นทางของคุณ ใช่ คุณควรยอมรับทั้ง requirements.in และ requirements.txt กับการควบคุมแหล่งที่มา

โปรดทราบว่าหากคุณกำลังปรับใช้ในสภาพแวดล้อม Python หลายรายการ (อ่านหัวข้อด้านล่าง) คุณจะต้องคอมมิตไฟล์เอาต์พุตแยกต่างหากสำหรับสภาพแวดล้อม Python แต่ละรายการ เราขอแนะนำให้ใช้รูปแบบ {env}-requirements.txt (เช่น win32-py3.7-requirements.txt , macos-py3.10-requirements.txt ฯลฯ)

การใช้งานข้ามสภาพแวดล้อมของ requirements.in / requirements.txt และ pip-compile

การขึ้นต่อกันของแพ็คเกจสามารถเปลี่ยนแปลงได้ขึ้นอยู่กับสภาพแวดล้อม Python ที่ติดตั้งไว้ ที่นี่ เรากำหนดสภาพแวดล้อม Python ว่าเป็นการผสมผสานระหว่างระบบปฏิบัติการ เวอร์ชัน Python (3.7, 3.8 ฯลฯ) และการใช้งาน Python (CPython, PyPy ฯลฯ) สำหรับคำจำกัดความที่แน่นอน โปรดดูการผสมผสานที่เป็นไปได้ของเครื่องหมายสภาพแวดล้อม PEP 508

เนื่องจาก requirements.txt ที่ได้อาจแตกต่างกันไปในแต่ละสภาพแวดล้อม ผู้ใช้จึงต้องดำเนินการ pip-compile บนสภาพแวดล้อม Python แต่ละระบบแยกกัน เพื่อสร้าง requirements.txt ที่ถูกต้องสำหรับแต่ละสภาพแวดล้อมดังกล่าว requirements.in เดียวกันนี้สามารถใช้เป็นไฟล์ต้นฉบับสำหรับทุกสภาพแวดล้อมได้ โดยใช้ตัวทำเครื่องหมายสภาพแวดล้อม PEP 508 ตามความจำเป็น เช่นเดียวกับที่ทำกับการใช้งาน pip ข้ามสภาพแวดล้อมปกติ

หาก requirements.txt ที่สร้างขึ้นยังคงเหมือนเดิมทุกประการสำหรับสภาพแวดล้อม Python ทั้งหมด ก็สามารถใช้ในสภาพแวดล้อม Python ได้อย่างปลอดภัย แต่ ผู้ใช้ควรระมัดระวังเนื่องจากการอัพเดตแพ็คเกจใด ๆ อาจทำให้เกิดการขึ้นต่อกันตามสภาพแวดล้อม ทำให้ requirements.txt ที่สร้างขึ้นใหม่ขึ้นอยู่กับสภาพแวดล้อมเช่นกัน ตามกฎทั่วไป ขอแนะนำว่าผู้ใช้ควรดำเนินการ pip-compile บนสภาพแวดล้อม Python แต่ละเป้าหมายเสมอเพื่อหลีกเลี่ยงปัญหา

เพิ่มความสามารถในการทำซ้ำสูงสุด

pip-tools เป็นเครื่องมือที่ยอดเยี่ยมในการปรับปรุงความสามารถในการทำซ้ำของบิลด์ แต่มีบางสิ่งที่ต้องจำไว้

• pip-compile จะให้ผลลัพธ์ที่แตกต่างกันในสภาพแวดล้อมที่แตกต่างกันตามที่อธิบายไว้ในส่วนก่อนหน้า
• ต้องใช้ pip กับตัวแปรสภาพแวดล้อม PIP_CONSTRAINT เพื่อล็อคการขึ้นต่อกันในสภาพแวดล้อมบิลด์ตามที่ระบุไว้ใน #8439
• การพึ่งพาอาศัยกันมาจากหลายแหล่ง

ดำเนินการต่อจากตัวอย่าง pyproject.toml จากก่อนหน้านี้ การสร้างไฟล์ล็อคไฟล์เดียวสามารถทำได้ดังนี้:

$ pip-compile --all-build-deps --all-extras --output-file=constraints.txt --strip-extras pyproject.toml
#
# This file is autogenerated by pip-compile with Python 3.9
# by the following command:
#
#    pip-compile --all-build-deps --all-extras --output-file=constraints.txt --strip-extras pyproject.toml
#
asgiref==3.5.2
    # via django
attrs==22.1.0
    # via pytest
backports-zoneinfo==0.2.1
    # via django
django==4.1
    # via my-cool-django-app (pyproject.toml)
editables==0.3
    # via hatchling
hatchling==1.11.1
    # via my-cool-django-app (pyproject.toml::build-system.requires)
iniconfig==1.1.1
    # via pytest
packaging==21.3
    # via
    #   hatchling
    #   pytest
pathspec==0.10.2
    # via hatchling
pluggy==1.0.0
    # via
    #   hatchling
    #   pytest
py==1.11.0
    # via pytest
pyparsing==3.0.9
    # via packaging
pytest==7.1.2
    # via my-cool-django-app (pyproject.toml)
sqlparse==0.4.2
    # via django
tomli==2.0.1
    # via
    #   hatchling
    #   pytest

แบ็คเอนด์บิวด์บางตัวอาจร้องขอการขึ้นต่อกันของบิวด์แบบไดนามิกโดยใช้ตะขอ get_requires_for_build_ ที่อธิบายไว้ใน PEP 517 และ PEP 660 สิ่งนี้จะถูกระบุในเอาต์พุตพร้อมกับส่วนต่อท้ายอย่างใดอย่างหนึ่งต่อไปนี้:

• (pyproject.toml::build-system.backend::editable)
• (pyproject.toml::build-system.backend::sdist)
• (pyproject.toml::build-system.backend::wheel)

เครื่องมือที่มีประโยชน์อื่น ๆ

• pip-compile-multi - wrapper คำสั่ง pip-compile สำหรับไฟล์ข้อกำหนดการอ้างอิงโยงหลายไฟล์

• pipdeptree เพื่อพิมพ์แผนผังการพึ่งพาของแพ็คเกจที่ติดตั้ง

• requirements.in / requirements.txt การเน้นไวยากรณ์:

  • Requirement.txt.vim สำหรับกลุ่ม
  • ส่วนขยาย Python สำหรับ VS Code สำหรับ VS Code
  • pip-requirements.el สำหรับ Emacs

การคัดค้าน

ส่วนนี้แสดงรายการคุณสมบัติ pip-tools ที่เลิกใช้แล้วในปัจจุบัน

• ในรุ่นหลักถัดไป ลักษณะการทำงาน --allow-unsafe จะถูกเปิดใช้งานตามค่าเริ่มต้น (#989) ใช้ --no-allow-unsafe เพื่อรักษาพฤติกรรมเก่า ขอแนะนำให้ส่ง --allow-unsafe ทันทีเพื่อปรับให้เข้ากับการเปลี่ยนแปลงที่กำลังจะเกิดขึ้น
• ตัวแก้ไขแบบเดิมเลิกใช้แล้วและจะถูกลบออกในเวอร์ชันต่อๆ ไป ค่าเริ่มต้นใหม่คือ --resolver=backtracking
• ในรีลีสหลักถัดไป ลักษณะการทำงาน --strip-extras จะถูกเปิดใช้งานตามค่าเริ่มต้น (#1613) ใช้ --no-strip-extras เพื่อรักษาพฤติกรรมแบบเก่า

หมายเหตุเกี่ยวกับตัวแก้ไข

คุณสามารถเลือกจากตัวแก้ไขการย้อนรอยเริ่มต้นหรือตัวแก้ไขแบบเดิมที่เลิกใช้แล้ว

ตัวแก้ไขแบบเดิมบางครั้งจะล้มเหลวในการแก้ไขการขึ้นต่อกัน ตัวแก้ไขการย้อนรอยมีประสิทธิภาพมากกว่า แต่โดยทั่วไปอาจใช้เวลานานกว่าในการทำงาน

คุณสามารถใช้ตัวแก้ไขแบบเดิมต่อไปได้โดยใช้ --resolver=legacy แม้ว่าโปรดทราบว่าตัวแก้ไขดังกล่าวเลิกใช้แล้วและจะถูกลบออกในรุ่นต่อๆ ไป