Názory k článku Model Context Protocol: vznikající standard pro aplikace AI a LLM

Prosim, neucte lidi instalovat veci pres `pip3 install --user`.

To lidi (pardon, Linuxy) zabiji...

Timhle si clovek muze velmi snadno rozdrbat cely system. Protoze i cast systemovych knihoven je zavisla na Python baliccich, ovsem ve verzich, se kterymi pocita distribuce, a ne s nahodnymi verzemi (idealne vydanymi vcera), ktere si vybere pip.

Spravny postup je:

python3 -m venv mcp-venv
. mcp-venv/bin/activate
python3 -m pip install mcp


Tohle mi docvalko teprve nedávno po tom, co asi 49 pokusů s --break-system-packages vyšlo, ale ten padesátý už ne.. :D Je to ale strašlivě otravné to venv. Kolem pythonu jsem vždy chodil oklikou, takže o tom moc nevím, ale bylo by hezké ty závislosti trochu automatizovat, ať si to ve složce projektu vyrobí třeba složku .venv a aktivuje si ji to automaticky, když v té složce jsem. Jako npm, composer, atd.

Od toho aby se to dělalo automaticky jsou jiné nástroje jako poetry atp.
Pak je ještě varianta použít pipx, který si udělá venv pro spustitelné aplikace.

Mě to celé, ale taky hrozně štve. V Python píšu hlavně jedno souborové scripty a na to je venv, poetry atp. prostě kanón na vrabce. Proč není ten systémový a uživatelský Python úplně oddělený, nebo proč to nejde udělat podobně jako v maven, kde může člověk mít spoustu verzí stejné knihovny a dělat import s tou konkrétní verzí např. podle project.toml.

kdysi dávno se někdo rozhodl, že knihovny budou uloženy v adresáři, kterej má stejnej název jako knihovna (zjednodušuju, ale +-) a nebude tam číslo verze. Zajímavý je, že hned vedle toho je adresář .dist-info s verzí, takže například máme:

requests
requests-2.31.0.dist-info

(toto je zrovna něco starého z Pythonu 3.11 - mám z určitých důvodů čtyři verze Pythonu).

Takže to kdysi šlo udělat líp, ale teď už je pozdě a řeší se to, jak píšeš, přes třetí tooly (poetry, pdm, uv a já už ani nevím kolik dalších).

Takže to kdysi šlo udělat líp, ale teď už je pozdě a řeší se to, jak píšeš, přes třetí tooly (poetry, pdm, uv a já už ani nevím kolik dalších).
A to je další věc co mě štve :-D . Prostě se nemůžu rozhodnout, který ten tool použít. Dřiv jsem používal Poetry, ale líbí se mi pyproject.toml (který Poetry 2 taky umí) ale PDM mi se mi líbí a teď mi příjde, že je moderní zase UV. Problém je, že žádný z těhle nástrojů není bez chyby a vždy mu něco chybí co jiný umí. Takže teď vyčkávám, kdo se z nich více prosadí a ten pak budu používat.

1. 4. 2025, 11:09 editováno autorem komentáře

no popravdě já to nechávám na pdm nebo uv, ale nechtěl jsem to komplikovat, protože potom je otázka, jak instalovat právě pdm/uv :-) Ale ano, je to pravda, --user může něco pokazit.

neinstaluje --user jenom do .local? Takze by to system jako takovy ovlivnit nemelo. jen skripty toho uzivatele nebo spoustene uzivatelem (to je vetsi problem asi)

Narazil jsem ještě na jedno vylepšení - není třeba volat activate, stačí zavolat mcp-venv/bin/pip install mcp a pak třeba mcp-venv/bin/python app.py a vše se provede v aktivovaném venv. Hodí se to hlavně v dockeru, kde místo entrypointu [ "bash", "-c", "source .venv/bin/activate; app.py" ] mohu použít entrypoint [ ".venv/bin/python", "app.py" ].

Jako velkou potíž venv vidím, že po aktualizaci pythonu v aplikaci musím vytvořit nový venv, takže script

#!/usr/bin/env bash

set -e
cd "$(dirname "$0")"
[[ -d .venv ]] || python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
.venv/bin/python app.py "$@"

nestačí, protože po aktualizaci pythonu ošklivě selže a uživatele nechá na holičkách.

Jo, takhle to dělám i na Windows v čistém Pythonu (bez venv). Stačí celá cesta k python(.exe) a v případě modulů (např. pip nebo uvicorn) volat přes ten python(.exe) -m modul. Python nic nepotřebuje, ani nic v PATH nebo jiných proměnných prostředí.

Zrovna jsem si říkal něco o tom napsat... a samozřejmě je Tišnovský rychlejší ;-)

tak to se omlouvám .)

Nás do toho docela natlačili, i když je fakt MCP ještě uvařenej tak napůl, takže to stejně budeme asi přepisovat

Není za co se omlouvat, hlavně, že to někdo napsal... a pěkně.

Pip má pro jistotu i přepínač --require-virtualenv, tedy
pip --require-virtualenv install ... by nemělo povolit instalaci do globálního prostředí.

Nechceme v roce 2025 už Python 2 ignorovat, a předstírat, že se na Python 3 už dávno přešlo?

myslím, že python 2 tady bude dokud nepříjde python 4 a python 4 zatím v plánu není...

Rozbíjet zpětnou kompatilbitu s sebou nese velká rizika. Vidíme to s python 2, on jen tak neumře, protože spoustu věcí ho prostě používá. Stejný případ je s Java 8. Prostě, když ke kódu nejsou rozumné testy, dokumentace, tak se strašně blbě dovnitř šahá.

Python 2 tady dost možná bude i když bude Python 6.
Jde mi o to, že kdo používá Python 2, ať si volá `python2`, a `python` v roce 2025 prostě znamená Python 3, a netřeba to explicitně zmiňovat.