Python venv, pipx au uv: ipi bora kwa seva ya Ubuntu?

Kwa nini pip install inashindwa kwenye seva mpya ya Ubuntu

Kuchagua kati ya Python venv, pipx na uv kwenye seva kunategemea swali moja: unaweka nini? Dependencies za programu zinapaswa kuwa ndani ya virtual environment iliyo ndani ya folda ya programu husika. Zana za mstari wa amri (command-line tools) unazotaka kuziita kwa jina zinapaswa kuwekwa kupitia pipx. uv hufanya kazi zote mbili na kuongeza lockfile, jambo ambalo huwa muhimu pindi mashine ya pili inapohitaji kujenga mazingira sawa. Hakuna hata moja kati ya hizi inayoweka faili kwenye Python ya mfumo, kwa sababu seva ya kisasa ya Ubuntu inakataa hilo moja kwa moja.

Endesha sudo pip install requests kwenye Ubuntu 24.04 na pip itasimama kabla haijapakua faili hata moja.

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this behaviour by passing --break-system-packages.

Hii ni PEP 668 (Python enhancement proposal 668, "mazingira yanayosimamiwa na nje") ikifanya kazi yake. Debian na Ubuntu huweka faili ya alama kando ya interpreter kwenye /usr/lib/python3.12/EXTERNALLY-MANAGED, na pip hukataa kuandika kwenye interpreter yoyote yenye faili hiyo.

Kanuni hii ipo kwa sababu ya mpangilio wa sys.path. apt huweka maktaba kwenye /usr/lib/python3/dist-packages. pip, ikiendeshwa kama root dhidi ya interpreter ya mfumo, huandika kwenye /usr/local/lib/python3.12/dist-packages, na ufungashaji wa Debian huweka folda hiyo mbele kwenye njia ya utafutaji (search path). Ichapishe mwenyewe kwa python3 -c 'import sys; print(sys.path)' na usome mpangilio huo. Kwa hivyo, nakala iliyoandikwa na pip hufunika nakala iliyowekwa na apt, kwa kila programu kwenye mashine inayoendeshwa chini ya /usr/bin/python3, ikijumuisha zana za usambazaji (distribution) zenyewe. cloud-init huagiza requests, jinja2 na PyYAML kutoka kwa interpreter hiyo. Ukiboresha mojawapo ya hizo kwa pip, na ukapata toleo lisiloendana, kitu ambacho hukugusa kitashindwa kufanya kazi wakati wa boot inayofuata kikiwa na traceback inayotaja kifurushi ambacho hukujua kama kilikuwa kwenye mnyororo huo. apt bado hurekodi toleo lake kama lililowekwa, kwa hivyo hakuna kinachokuonya, na ukarabati wake ni sudo apt reinstall python3-requests.

Kanuni inayofuata ni fupi. Python ya mfumo ni mali ya usambazaji (distribution). Usiweke faili ndani yake, usiboreshe maktaba zake kwa pip, na usifute faili ya EXTERNALLY-MANAGED ili kuondoa ujumbe huo. Kazi pekee ya kuipa /usr/bin/python3 ni kujenga virtual environments.

venv dhidi ya pipx dhidi ya uv: kanuni ya maamuzi

Chagua kulingana na kile unachokisakinisha, si kulingana na zana uliyosoma kuihusu hivi karibuni.

• Programu unayoipeleka na kuiendesha kama huduma, kama vile mradi wa Django au Flask: tumia virtual environment (venv) moja ndani ya saraka ya programu hiyo.
• Zana ya mstari wa amri (command-line tool) unayotaka kwenye PATH yako, kama vile ansible au httpie: tumia pipx, ambayo huipa kila zana mazingira ya faragha na kiungo kimoja kwenye PATH.
• Mradi unaohitaji lockfile, usakinishaji wa haraka, au toleo la Python ambalo usambazaji (distribution) haujatoa: tumia uv, ambayo hutengeneza venv ya kawaida pamoja na faili ya uv.lock.
• Maktaba (library) ambayo zana ya usambazaji inahitaji badala ya msimbo wako: tumia sudo apt install python3-<name>, njia pekee inayoungwa mkono ya kuongeza chochote kwenye mkalimani (interpreter) wa mfumo.

pipx na uv tool install hufanya kazi sawa, kwa hivyo mashine ambayo tayari ina uv haihitaji pipx pia. Mfumo wa wavuti (web framework) uliouchagua haubadilishi chochote hapa: Django na Flask kwenye VPS hutofautiana katika kile kinachotua kwenye requirements.txt, si katika jinsi mazingira yanayozunguka yanavyojengwa. Kila kitu hapa chini kinatumia Ubuntu 24.04 na Python 3.12 yake, kwa hivyo rekebisha toleo ndani ya njia (paths) ikiwa la kwako ni tofauti.

Jenga venv kwa kila programu

Ubuntu hutenganisha moduli ya venv kutoka kwenye kifurushi cha msingi cha Python, kwa hivyo kwenye picha ndogo (minimal image) jaribio la kwanza litafeli na ujumbe unaotaja hasa kile kinachokosekana.

The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

    apt install python3.12-venv

Isakinishe, kisha uunde mazingira hayo kama mtumiaji atakayemiliki msimbo huo.

sudo apt update
sudo apt install -y python3-venv
sudo install -d -o deploy -g deploy -m 755 /srv/myapp
sudo -u deploy python3 -m venv /srv/myapp/.venv
sudo -u deploy /srv/myapp/.venv/bin/pip install -r /srv/myapp/requirements.txt

Angalia kile kisichokuwepo: hakuna source, hakuna activate. /srv/myapp/.venv/bin/pip husakinisha ndani ya mazingira hayo kwa sababu ya mahali faili ya binary ilipo, si kwa sababu ya kitu chochote ulichokiingiza (export) kwenye shell. Ithibitishe kabla ya kuendelea zaidi.

/srv/myapp/.venv/bin/python -c 'import sys; print(sys.prefix)'

Hiyo huchapisha /srv/myapp/.venv. Ikiwa itachapisha /usr, unatumia mkalimani (interpreter) wa mfumo na vifurushi vyako vimeenda mahali ambapo hukukusudia.

Sifa mbili za venv huamua kile unachoweza kufanya nayo baadaye. Venv haiwezi kuhamishika, kwa sababu kila hati katika bin/ ina mstari kamili wa shebang: head -1 /srv/myapp/.venv/bin/pip husoma #!/srv/myapp/.venv/bin/python. Badilisha jina la saraka kuu na hati hizo zitafeli kwa bad interpreter: No such file or directory. Venv pia hufunga mkalimani aliyeiunda, uliorekodiwa kama mstari wa home katika /srv/myapp/.venv/pyvenv.cfg, na bin/python3 ni symlink ya binary hiyo. Boresha toleo la mfumo ili python3.12 itoweke, symlink itakosa lengo, na huduma itakufa wakati wa kuanza kwa No such file or directory. Kesi zote mbili zina suluhisho moja: futa venv na ujenge mpya kutoka requirements.txt. Kujenga upya huchukua sekunde chache. Usiwahi kunakili venv kati ya mashine tofauti.

Mahali venv inapoishi, na nani anayeimiliki

Iweke kando ya msimbo kwenye /srv/myapp/.venv, na utumie venv moja kwa kila programu. Upelekaji wa programu (deployment) unakuwa saraka moja, unit ya systemd inapata njia (path) isiyobadilika, na programu mbili haziwezi kuharibiana kupitia uboreshaji wa dependency moja inayoshirikiwa. Usiweke venv popote ambapo seva yako ya wavuti huchapisha faili moja kwa moja, kwa sababu inashikilia dependencies zako na mara nyingi usanidi wako.

Umiliki unahitaji umakini kidogo. Ruhusu mtumiaji wa deploy amiliki msimbo na mazingira, na upe akaunti ya huduma (service account) ruhusa ya kusoma na kutekeleza pekee.

sudo adduser --system --group --no-create-home myapp
sudo chown -R deploy:myapp /srv/myapp
sudo chmod -R o-rwx /srv/myapp

Huduma sasa inaweza kuingiza (import) dependencies zake lakini haiwezi kuzibadilisha, jambo linalomaanisha kuwa hitilafu ya utekelezaji wa msimbo katika programu ya wavuti haiwezi kubadilisha maktaba (library) kwenye diski kimyakimya na kuendelea kuwepo baada ya kuanzisha upya. Hoja hiyo hiyo inayotumika kwa sehemu nyingine ya mashine imeelezewa katika kuendesha huduma kama watumiaji wenye upendeleo mdogo.

pipx kwa ajili ya zana za mstari wa amri (command-line tools)

pipx husakinisha programu, si maktaba (libraries). Kila zana hupata mazingira yake ya kipekee chini ya ~/.local/share/pipx/venvs/<name>, na faili za kutekeleza (executables) za zana hiyo huunganishwa kwenye ~/.local/bin, hivyo zana mbili zinazohitaji matoleo tofauti ya maktaba moja hazitapata mgongano.

sudo apt update
sudo apt install -y pipx
pipx ensurepath
pipx install httpie

pipx ensurepath huongeza ~/.local/bin kwenye PATH kwa kuhariri faili ya kuanzisha shell yako. Haiwezi kubadilisha shell uliyopo sasa, kwa hivyo http: command not found mara tu baada ya usakinishaji kwa kawaida inamaanisha kuwa hujatoka (log out) na kuingia tena (log in). ~/.profile ya kawaida ya Ubuntu huongeza ~/.local/bin pale tu saraka hiyo inapokuwepo wakati wa kuingia, ndiyo maana tatizo hili hutokea mara moja kwenye akaunti mpya na halijirudii tena.

Ukielekeza pipx kwenye maktaba, itakataa, ikiwa na ujumbe unaoanza hivi:

No apps associated with package requests or its dependencies.

Hiyo ni zana inayokuambia kuwa unatumia kifaa kisichofaa. Maktaba ni za venv ya programu.

Maelezo muhimu kwenye seva ni eneo. pipx install ya kawaida huweka kila kitu chini ya saraka ya nyumbani ya mtumiaji mmoja. Unit ya systemd inayofanya kazi kama myapp haiwezi kuiona, cron job ya root haiwezi kuiona, na sudo pia haitaipata, kwa sababu secure_path katika /etc/sudoers hubadilisha PATH na orodha isiyobadilika. Kwa zana ambayo mashine nzima inapaswa kuwa nayo, isakinishe kimataifa (globally).

sudo pipx install --global ansible
sudo pipx ensurepath --global

Flag ya --global huweka mazingira katika /opt/pipx na kuunganisha faili za kutekeleza katika /usr/local/bin, ambayo iko kwenye PATH ya kawaida na ndani ya secure_path. Angalia toleo lako kwanza kwa pipx --version, kwa sababu Ubuntu 24.04 ina vifurushi vya pipx 1.4.3, ambavyo ni vya zamani kuliko --global, na pipx ya zamani hujibu kwa unrecognized arguments: --global. Kwenye toleo hilo, weka saraka mbili zilizotajwa wewe mwenyewe:

sudo env PIPX_HOME=/opt/pipx PIPX_BIN_DIR=/usr/local/bin pipx install ansible
command -v ansible

command -v ansible inapaswa kuchapisha /usr/local/bin/ansible. Ikiwa inachapisha njia (path) chini ya /home, zana hiyo imeingia kwenye akaunti ya mtumiaji mmoja na hakuna huduma itakayoipata.

uv wakati unahitaji lockfile

uv ni binary moja kutoka Astral inayoshughulikia kazi za pip, venv na pip-tools, na inaweza kupakua interpreters pia. Ina kasi ya kutosha kiasi kwamba tofauti huonekana kwenye VPS ndogo, na huandika lockfile halisi.

Kisakinishi rasmi huweka uv na uvx kwenye ~/.local/bin:

curl -LsSf https://astral.sh/uv/install.sh | sh
uv --version

Kupeleka script kwenye shell ya seva kunahitaji umakini kidogo. Funga toleo (pin) kwenye URL na usome faili kabla ya kuiendesha:

curl -LsSf https://astral.sh/uv/0.12.3/install.sh -o uv-install.sh
less uv-install.sh
sh uv-install.sh

pipx install uv inafanya kazi pia, ikiwa pipx tayari ipo. uv ni binary moja inayojitegemea bila kutegemea Python yoyote, kwa hivyo kuinakili kwenye /usr/local/bin ni njia sahihi ya kuishiriki na kila mtumiaji kwenye seva.

Kwa mradi wenye pyproject.toml, workflow ni amri nne, na ya mwisho pekee ndiyo huendeshwa kwenye seva.

uv init myapp
uv add flask gunicorn
uv lock
uv sync --frozen --no-dev

uv lock huandika uv.lock, lockfile ya cross-platform inayoshikilia matoleo kamili yaliyotatuliwa, na unaifanyia commit karibu na code yako. uv sync hujenga .venv kwenye mzizi wa mradi ili kuendana nayo. Kwenye seva, --frozen ndiyo flag muhimu: nyaraka zinaifafanua kama kutumia matoleo yaliyomo kwenye lockfile kama chanzo cha ukweli badala ya kuangalia kama lockfile imepitwa na wakati, tabia ambayo ni muhimu kwa deployment. --no-dev huacha kundi la development dependency.

Mradi uliopo wa requirements.txt hauhitaji kubadilishwa, kwa sababu uv inaelewa lugha ya pip:

uv venv /srv/myapp/.venv
uv pip install --python /srv/myapp/.venv/bin/python -r /srv/myapp/requirements.txt

Kinachotokea ni virtual environment ya kawaida. .venv/bin/python hufanya kazi kama vile python3 -m venv ingeijenga, kwa hivyo hakuna kitu kitakachobadilika baadaye katika mwongozo huu.

Kuna default moja ya uv inayofaa kujulikana kabla ya kuitumia kwenye seva. Mpangilio wake wa python-preference huwa managed, ambao umeandikwa kama kuchagua "zile zilizopakuliwa na kusakinishwa na uv" badala ya interpreters zilizopo kwenye mfumo. Kwa hivyo uv venv --python 3.13 kwenye seva inayokuja na 3.12 pekee itapakua 3.13 kimyakimya kwenye ~/.local/share/uv/python badala ya kufeli. Hii ni rahisi kwenye laptop lakini inashangaza kwenye seva, kwa sababu huduma yako sasa inategemea interpreter iliyo kwenye home directory ambayo apt upgrade haitawahi kuifanyia patch. Weka python-preference kuwa only-system kwenye uv.toml ikiwa unataka kutumia interpreter ya mfumo (distribution). Ikiwa unataka mazingira (environment) yawe mahali pengine nje ya mzizi wa mradi, UV_PROJECT_ENVIRONMENT hubainisha directory ya kutumia kwa ajili ya virtual environment ya mradi.

Elekeza systemd kwenye interpreter ya venv, siyo kwenye activate

Hapa ndipo deployments nyingi za Python zinapofeli, na sababu ni kutoelewa kile ambacho activate hufanya.

bin/activate ni hati ya shell. Inaongeza saraka ya bin ya venv kwenye PATH, inaweka VIRTUAL_ENV, inahifadhi thamani za zamani ili deactivate iweze kuzirejesha, na inabadilisha prompt yako. Haina chochote ambacho interpreter yenyewe inakisoma. Activation ni urahisi kwa binadamu anayeandika python kwenye prompt.

Kinachochagua mazingira (environment) kwa hakika ni faili gani ya interpreter unayoiendesha. Wakati /srv/myapp/.venv/bin/python inapoanza, moduli ya site ya Python hutafuta faili ya pyvenv.cfg katika saraka iliyo na executable hiyo na ngazi moja juu yake. Kupatikana kwa /srv/myapp/.venv/pyvenv.cfg huweka sys.prefix kwenye venv, jambo ambalo huweka site-packages ya venv hiyo kwenye sys.path. Huo ndio utaratibu mzima. Haihitaji variable yoyote ya mazingira wala shell.

Kwa hivyo unit hii haiwaki kamwe:

[Service]
ExecStart=source /srv/myapp/.venv/bin/activate && gunicorn app:app

myapp.service: Failed to locate executable source: No such file or directory
myapp.service: Failed at step EXEC spawning source: No such file or directory
myapp.service: Main process exited, code=exited, status=203/EXEC

ExecStart si mstari wa amri ya shell. systemd huendesha programu moja kwa moja, kwa hivyo hakuna source builtin, && inapitishwa kama argument halisi, na hakuna kinachopanuka.

Na unit hii inawaka, kisha inakufa:

[Service]
ExecStart=/usr/bin/python3 /srv/myapp/app.py

ModuleNotFoundError: No module named 'flask'

/usr/bin/python3 ni interpreter ya mfumo, na sys.path yake haijawahi kuwa na venv yako. Amri hiyo hiyo inafanya kazi katika kikao chako cha SSH kwa sababu tu ulikuwa ume-activate venv huko, hivyo shell ilitatua python3 kupitia PATH hadi .venv/bin/python3 badala yake.

Kufunga amri hiyo ndani ya /bin/bash -c 'source ... && gunicorn ...' kunafanya kazi. Pia kunaweka shell kati ya systemd na mchakato wako bila faida yoyote, wakati njia moja kamili (absolute path) inatatua tatizo:

[Unit]
Description=myapp web service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/srv/myapp
Environment=PYTHONUNBUFFERED=1
Environment=PATH=/srv/myapp/.venv/bin:/usr/local/bin:/usr/bin:/bin
ExecStart=/srv/myapp/.venv/bin/gunicorn --workers 3 --bind 127.0.0.1:8000 app:app
Restart=on-failure
RestartSec=5
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=full

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
journalctl -u myapp -n 50 --no-pager

systemctl status myapp inapaswa kuripoti active (running) ikiwa na Main PID ambayo ni mchakato wako wa gunicorn. Kitu kingine chochote, soma journal.

Mstari wa Environment=PATH= haupo kwa ajili ya ExecStart, ambayo tayari inabeba njia kamili. Upo kwa ajili ya michakato ambayo programu yako inaiwasha. Huduma hurithi PATH fupi ya msingi kutoka kwa systemd, kwa hivyo msimbo wa Python unaoita subprocess.run(["ffmpeg", ...]), au amri ya usimamizi inayotumia console script kutoka kwenye venv, haitapata kile inachohitaji. Kuweka saraka ya bin ya venv kwanza ndiyo sehemu pekee ya activate ambayo huduma inaitumia kikweli. Angalia kile ambacho unit ilipokea kweli kwa kutumia systemctl show -p Environment myapp.

Kanuni hiyo hiyo inahusu kazi zilizopangwa. cron huendesha kazi na PATH ya /usr/bin:/bin, kwa hivyo mstari wa crontab unaosomeka python3 /srv/myapp/cleanup.py huendesha interpreter ya mfumo na kufeli kwa ModuleNotFoundError saa tisa usiku, na kosa huenda kwenye local mail spool ambayo hakuna anayesoma. Andika njia kamili ya venv hapo pia. Ili kupata matokeo hayo kwenye journal na rekodi ya uendeshaji wa mwisho badala yake, jozi ya systemd service na timer inachukua mstari uleule wa ExecStart.

Je, Docker inachukua nafasi ya uamuzi huu?

Container ina mfumo wake wa faili, kwa hivyo swali hubadilika umbo badala ya kutoweka. Katika image rasmi kama python:3.12-slim, Python imejengwa ndani ya /usr/local na haina alama ya EXTERNALLY-MANAGED, kwa hivyo pip install kama root ndiyo njia iliyokusudiwa ya kuongeza vifurushi na venv haiongezi faida kubwa. Jenga FROM ubuntu:24.04 badala yake na utakutana na externally-managed-environment tena ndani ya image, kwa sababu ile ile kama ilivyo kwenye host: ni interpreter ya distribution inayobeba faili la alama la distribution hiyo.

Image nyingi bado hutumia venv, kwa sababu hufanya multi-stage build kuwa rahisi. Hatua ya builder husakinisha kwenye /opt/venv, na hatua ya runtime hunakili saraka hiyo moja na kuacha compilers nyuma. Tatizo la activate husafiri nayo. Mstari wa RUN source /opt/venv/bin/activate huathiri shell ya safu hiyo ya build pekee, kwa hivyo wakati wa runtime container huanza kwenye system interpreter na kuibua ModuleNotFoundError. Weka ENV PATH="/opt/venv/bin:$PATH", au ipe CMD njia kamili ya /opt/venv/bin/gunicorn. Ni hitilafu ile ile kama ya systemd, katika faili tofauti.

Kwa hivyo container inachukua nafasi ya swali la interpreter, kwa sababu image hufunga (pin) interpreter na kila kitu kilicho chini yake. Haichukui nafasi ya swali la kufunga matoleo (pinning). Image iliyojengwa kutoka kwa requirements.txt isiyofungwa itatatua matoleo tofauti mwezi ujao, jambo linalomaanisha kuwa image tag inaweza kurudiwa wakati build iliyoizalisha haiwezi. Lockfile kama uv.lock, au faili la requirements lililofungwa kikamilifu, ndilo linaloziba pengo hilo, iwe ni container au la. Na wakati programu moja inapoendeshwa kwenye VPS moja chini ya systemd, container mara nyingi huhamishia uamuzi huu kwenye Dockerfile, kwa kuwa systemd tayari huanzisha upya mchakato ulioshindwa na kunasa matokeo yake kwenye journal. Kuendesha Docker kwenye VPS inafaa wakati unataka image iliyojengwa yenyewe ndiyo iwe kitu unachopeleka (deploy).

FAQ

Je, ninaweza kutumia pip install pamoja na --break-system-packages?

Hapana, usifanye hivyo kwenye seva unayohitaji iendelee kufanya kazi. Flag hiyo hufanya kile inachosema: huondoa kinga, na pip huandika ndani ya /usr/local/lib/python3.12/dist-packages, ambayo inatangulia saraka ya apt kwenye sys.path. Toleo lako kisha hufunika toleo la mfumo kwa kila hati ya mfumo inayotumia /usr/bin/python3, na apt bado huamini kuwa toleo lake ndilo lililosakinishwa, kwa hivyo hakuna kinachogundua mgongano huo hadi kitu kiharibike. Ndani ya container image unayounda upya kila mara, uharibifu huishia kwenye image hiyo, kwa hivyo inaweza kukubalika hapo. Kwenye mashine unayoisimamia, tengeneza venv. Hiyo ni amri moja tu.

Virtual environment inapaswa kukaa wapi kwenye seva?

Ndani ya saraka ya programu yenyewe, kama /srv/myapp/.venv, inayomilikiwa na mtumiaji wa deploy, huku akaunti ya huduma ikiwa na ruhusa ya kusoma na kutekeleza pekee. Weka venv moja kwa kila programu, kwa sababu venv ya pamoja inamaanisha kuwa uboreshaji wa programu ya kwanza unaweza kuharibu ya pili. Usihamishe au kunakili venv baada ya kuitengeneza: kila hati katika saraka yake ya bin/ ina njia hiyo kamili (absolute path) iliyoandikwa kwenye mstari wake wa shebang, kwa hivyo venv iliyohamishwa itashindwa na kutoa bad interpreter: No such file or directory. Ifute na uijenge upya kutoka requirements.txt badala yake.

Kwa nini huduma yangu ya systemd inashindwa na kutoa ModuleNotFoundError?

Kwa sababu unit inatekeleza interpreter ambayo si ya venv. Tekeleza systemctl cat myapp na usome ExecStart. Ni lazima itaje /srv/myapp/.venv/bin/python, au console script kutoka saraka hiyo hiyo ya bin/, kwa njia kamili. Ku-source activate kwenye faili ya unit hakuwezi kufanya kazi, kwa sababu ExecStart si shell, na systemd huripoti Failed to locate executable source kwa status=203/EXEC. Ongeza Environment=PATH=/srv/myapp/.venv/bin:/usr/local/bin:/usr/bin:/bin ili mchakato wowote mdogo (subprocess) unaoanzishwa na msimbo wako uweze kupata zana za venv pia.

Je, nitumie uv badala ya venv na pip?

Tumia uv unapotaka lockfile, wakati muda wa kusakinisha ni mrefu kiasi cha kukuudhi, au unapohitaji toleo la Python ambalo mfumo wako hautoa. Inatengeneza venv ya kawaida, kwa hivyo unit ya systemd na mpangilio wa faili havibadiliki, na uv sync --frozen husakinisha kile ambacho lockfile inarekodi kikamilifu. Ikiwa programu moja inatumwa kutoka git na requirements.txt iliyofungwa (pinned) na usakinishaji unakamilika kwa sekunde chache, python3 -m venv inatosha, na ni binary moja pungufu ya kuhuisha kwenye seva.