Názory k článku PDM: moderní správce balíčků a virtuálních prostředí Pythonu
-
Po mnoha letech s Pythonem jsem konečně u projektů schopen vše managovat jen za pomoci základní knihovny. Povětšinou jsem úspěšně přešel všude na pyproject.toml (setup.py/cfg jen z lenosti či pro speciální účely).
Čekám v podstatě jen na dodělání toho, co má node.js ekosystém léta. Prošel jsem si přes pipenv, poetry a jiné a jak by řekl Bartleby: "Já bych raději ne" (K poetry chovám větší respekt).
Mám(e) většinou .venv per projekt. Pro jednu organizaci (zaměstnavatele) jsem nedávno přešel na jeden .venv per organizaci (pohodlnost a praktičnost)
Funguju na Windows i Debian a nemám problém nepoužívat Conda, Pipenv, Poetry. A to je dobře.
Tyhle všechny nástroje ale plní důležitou funkci. Kopou PSF do zadku aby s tím něco dělala. A to je dobře.
:D
19. 10. 2023, 09:23 editováno autorem komentáře
-
Je to ještě horší, existuje několik stejně špatných neoficiálních řešení. A ani se neptej pokud dva externí balíky pracují s jinou verzi jiného. Nějak jsem to déle nestudoval, ale myslím že to je "hot topic" v dizkusích k nástroji `pip`.
https://peps.python.org/pep-0665/
20. 10. 2023, 10:33 editováno autorem komentáře
-
ten defaultni v podstate ne.
ale divnej je mindset nekterych pythonistu (proto jsem se ptal) - nekteri povazuji za skvelej napad nemit nastaveny verze a proste busi oproti latest (coz ale neni pravda, vlastne vetsina neupdatuje, takze davno latest nemaji). Oproti Go/Rustu, kde vyvojari vi, co a jak, je to v Python ekosystemu horsi (a jeste o to horsi, ze problem s typo squattingem atd. se netyka jen npm, ale i pypi). Proste se u nas vlastne jen ceka na vetsi pruser.
-
Tam bych viděl několik různých příčin.
1. Sémantické verzování a hlavně jeho absence. Jestliže jsou knihovny, které mají pořád verzi 0.xy, v zásadě není žádná verze, na kterou by se dalo spolehnout, že bude stabilní z pohledu API a zároveň tam někdo bude opravovat chyby. Sledovat každou konkrétní závislost je obecně dost problém a "sleduj poslední" je suboptimální, ale poměrně intuitivní.
2. Problém "kdo vládne". Python byl původně stavěný na filosofii "batteries included", takže se dalo rozumně spoléhat na to, že tam je "správná" verze modulu a ta funguje. Pak je tam operační systém a jeho balíčky, kde jsou různé závislosti už zadrátované v systému a pip se o ně musí prát. A samozřejmě - globální vs. uživatelská instalace, případně virtualenv. Píšeš, že vývojáři v Rustu a Go vědí, ale na rozdíl od Rustu a jeho standardního systému Cargo-crates Go mělo původně závislosti řešeny dost komicky (odkazem na nějaký repozitář na GitHubu) a rozumnější správa závislostí se tam dodělávala horkotěžko ex post. V Pythonu je třeba svést boj o to, jestli má závislosti kompletně produkt samotný nebo jestli si je tahá z globálu. Oba přístupy mají svoje nevýhody, ale podle všeho je správně ta první možnost.
3. Otázka, jestli nějakou vrstvu řeší společný základ (jako cargo) nebo nějaká externí nadstavba (jako Poetry apod.). První možnost je asi lepší, druhá ale není takový problém. Lockfile, jak jsem koukal, podporuje Poetry i PDM a Hatch to má v plánech.Za mě tedy pro Python všechno je - stačí se v projektu domluvit, že se bude používat třeba Poetry a závislosti jsou v klidu. Ale je fakt třeba vyřešit výše zmíněná dilemata (a případná další). Ale od toho jsme kvalifikovaní vývojáři, ne? ;-)
-
Pavel TišnovskýZlatý podporovatelsnaha u nás je. + snaha o podporu aspoň tří verzí Pythonu, vždycky aktuální a +- jedna další. Je to někdy boj, jak udržet jak "matrix" verzí Pythonu, tak i lockované závislosti. Ale asi to jinak rozumně nejde, pokud máme být připraveni na přechod na novou verzi, když té stabilní skončí security podpora.
-
Ješte bych doplnil, že tyhle nástroje přidávají vlastní sekce do pyproject.toml namísto aby pracovali s již existující.
proč
[tool.pdm.dev-dependencies] dev = [ "pytest>=7.4.2", ]a ne prostě
[optional-dependencies] dev = [ "pytest>=7.4.2", ]A takhle přesně prasí poetry. Už tak větší zmatek v balíčkování pro začínající programátory, kteří chtějí Pythonu opravdu rozumět.
Asi nějaká pomsta za to, jak je Python "jednoduchý", udělat ten ekosystém tak zmatený. Rust to měl dobře na první dobrou. Tady se 30 let točíme na pětníku.
19. 10. 2023, 09:34 editováno autorem komentáře
-
Argument, že se to dávalo běžné je fakt hodně hloupý. Je třeba rozlišovat mezi dependencies co jsou použité v běhu aplikace (required, optional) a dependencies, které jsou pro vývoj, test, dokumentace atp. ty rozhodně nejsou optional a nikoho kdo používá aplikaci/knihovnu nezajímá, co se pro to použilo.
Např. Mám knihovnu v Python, která implementuje Git a vyžaduje (required) http a také umí ssh, ale to není potřeba dokud ho uživatel nepoužije (optional). Celou aplikaci pak testují pytest (test). Míchat tohle dohromady je pěkná blbost. -
Jak jsem psal, řešilo s e to většinou takto.
```
pip install pakage[ssh]
```
A pro vývoj
```
pip install package[dev]
```
nebo```
pip install -r requirements-dev.txt
```Jinak to ani dřív nešlo.
ta diskuze co jsem posílal je, jestli se to nemá oddělovat, což je dobrý postřeh, asi ano. Ale je dobré to řešit nikoliv nějakými externími nástroji, ale dohodnout to oficiálně. Po kom deš? :D
21. 10. 2023, 12:40 editováno autorem komentáře
-
Vtipný je, že třeba knihovna kterou tu "jakoby" zmiňujete to dělá přesně jak bylo popsáno.
Takže, ne že bych s vámi v principu nesouhlasil, určitě to v jiných jazycích/prostředích dělají lépe, ale v Pythonu se to léta dělalo takto. Pokud si uživatel instaluje balík se závislostma pro testování je to jeho věc.
"Fakt hloupý " mi spíš přijde hodnotit bez toho aniž bych si prošel ty odkazy nebo jiné projekty.
21. 10. 2023, 16:55 editováno autorem komentáře
-
1. To byl jenom příklad.
2. Právě, že to ostatní jazyky dělají jinak, a dle mého názoru lépe, a protože i vím, jak se tohle
"prasí" v Pythonu, mě vede k tomu, že míchat optional a podpůrné dependency je blbost.Můžeš si tu psát co chceš o tom, že se to tak dělá, ale to neznamená, že to nejde dělat lépe. A hlavně u toho tvého příkladů jsem uvedl proč to asi nenacpali do optional a udělali vlastní sekci. Tohle ale není problém PDM, ale toho, že celý dependency v pyproject.toml (a obecně pyproject.toml) je značně nedotažený. Vlastně se stalo to co se často stává. Máme 15 způsobů, jak něco dělat pojďme udělat nový, který je nahradí a místo toho máme 16 a nic se nevyřešilo. Vždyť ani pip neumí instalovat dependencies rovnou z pyproject.toml, a to bych očekával jako minimální nutnost k tomu aby to k něčemu bylo. Takže to vlastně je obyčejný config file, kam si každý nástroj může zapsat co chce nic víc nic míň. Což je obrovská škoda, protože by to práci s pythonem dosti usnadnilo.
-
"Tohle ale není problém PDM, ale toho, že celý dependency v pyproject.toml (a obecně pyproject.toml) je značně nedotažený. " O tom je snad celá debata. Tvůj postřeh, že develeopment dependencies nepatří do optional je sice pravdivý, ale řešení na něj zatím nikdo nemá. Prakticky to vlastně vůbec nevadí, že je to strčený pod sekcí "optional", víc mi vadí, že si to každý nástroj začne managovat jinak. V setup.py se to nazývalo extras a klíč říkal co pod tím extras máš na mysli ... to asi nikoho nedráždilo. Názvosloví mne zas tak netrápí.
"Vždyť ani pip neumí instalovat dependencies rovnou z pyproject.toml" Na to jsi přišel jak? Ty píšeš v Pythonu nebo to jen tak tipuješ? Nebo jsem tě nepochopil.
21. 10. 2023, 21:06 editováno autorem komentáře
-
O tom je snad celá debata.
Ne není. Celá debata je o tom, že chceš míchat jablka a hrušky dohromady.
Prakticky to vlastně vůbec nevadí, že je to strčený pod sekcí "optional"
Prakticky to právě vadí. Vadí to mě vadí to skoro všem nástrojům a proto taky zavádí svoje vlastní definice. Protože je to blbost. Je to jako když vaří Babica, nemáte to kam dát tak dej tam.Na to jsi přišel jak? Ty píšeš v Pythonu nebo to jen tak tipuješ? Nebo jsem tě nepochopil.
Nejde nahradit requirements.txt pomocí pyproject.toml. Pro jednoduché skripty chci definovat jenom pár dependencies typicky requests atp. -
Az na to ze nikde neni jasne co myslis tema jabkama a hruskama.
Jaky podstatny rozdil je podle tebe kdyz to uvedes v extras_require pod klicem test nebo dev?
Pro tebe bude asi https://peps.python.org/pep-0722/
Mas s Pythonem zkusenosti s vetsim projektem?
22. 10. 2023, 09:45 editováno autorem komentáře
-
Az na to ze nikde neni jasne co myslis tema jabkama a hruskama.
Jsi natvrdlý nebo to děláš naschvál? Celou dobu tu píšu o tom, že mixovat věci co se používají v runtime a věci co se používají pro vývoj (pouze podpůrné) a s runtime nemají nic společného a uživatele knihovny/aplikace vůbec nezajímají.
Jaky podstatny rozdil je podle tebe kdyz to uvedes v extras_require pod klicem test nebo dev?
Naprosto žádný. To, že je to blbost nemusím dodávat. Je to přesně to míchání. To, že se to tak používá na tom, že je to blbost, nic nemění.
Pro tebe bude asi https://peps.python.org/pep-0722/
Já ten pep znám a je to přesně to co jsem psal. Máme dva standardy, které se nedají použít všude, tak přidáme třetí. To, že je rejected nemusím dodávat. Má ho nahradit https://peps.python.org/pep-0723/ , který "překvapivě" používá embedded pyproject.toml. -
Samozrejme ze ti to delam naschval, kdyz v jedne odpovedi michas tri veci dohromady a na blbosti co jsi napsal nereagujes. Tvuj dobry postreh, ze developmnet dependencies jsou neco jineho nez optional je v teoreticke rovine pravdivy. Kdybys zustal u toho rekl bych si ze je to dobry postreh k diskuzi. Ale vzhledem k tomu, ze ale ani po letech nema oficialni reseni a prakticky to moc nevadi, tak mi tvoje dalsi nazory jsou k nicemu. A to dalsi co si k tomu nabalil jsou vykriky kolem.
A to ze jsi o jeden PEP napred je fajn, ale jak pisou v dizkuzi: "So this was not an easy decision to make between PEP 722 and PEP 723". https://discuss.python.org/t/pep-722-723-decision/36763 Popravde jsem si nevsim ze ho mezitim rejetly -- ale to je jina pohadka.
Psat o nekom ze je natvrdly muzes, ale nicim si nepomuzes.
22. 10. 2023, 12:02 editováno autorem komentáře
-
Tvuj dobry postreh, ze developmnet dependencies jsou neco jineho nez optional je v teoreticke rovine pravdivy. Kdybys zustal u toho rekl bych si ze je to dobry postreh k diskuzi. Ale vzhledem k tomu, ze ale ani po letech nema oficialni reseni a prakticky to moc nevadi, tak mi tvoje dalsi nazory jsou k nicemu.
Jak už jsem ukázal, tak to vadí.
Samozrejme ze ti to delam naschval, kdyz v jedne odpovedi michas tri veci dohromady a na blbosti co jsi napsal nereagujes.
...
Psat o nekom ze je natvrdly muzes, ale nicim si nepomuzes.
To jsem napsal, právě protože mi bylo jasné, že to děláš naschvál.
Mimochodem, jaké blbosti konkrétně jsem napsal? Stále dokola píši o jedné a té samé věci a to, že chceš aby se míchaly neruntime, neoptional dependencies do optional dependencies, když tam evidentně nepatří. To na co ses následně upnul měla být jenom ukázka, že pyproject.toml není vůbec dotažený nic víc nic míň.A to ze jsi o jeden PEP napred je fajn, ale jak pisou v dizkuzi: "So this was not an easy decision to make between PEP 722 and PEP 723". https://discuss.python.org/t/pep-722-723-decision/36763 Popravde jsem si nevsim ze ho mezitim rejetly -- ale to je jina pohadka.
Možná dobrá rada, když už chceš někoho poučovat, tak je dobré si to nejdřív ověřit. -
Torchu jsem se ztratil v tom, kdo zastává co, ale snad vám to k něčemu bude:
v PHP, v nástroji composer je přepínač --no-dev a v konfiguraci balíčků tři sekce:
require - sekce pro závislosti
require-dev - sekce pro závislosti vývojové. Například tam dávám lokální nástroje pro build, test a podobně.
suggest - Sekce, která na výstup informuje, že by se vám možná mohl hodit například konkrétní adaptér.V Rust jsou sekce: [dev-dependencies] a [profile.dev] které jsou koncipované trošičku jinak ale v podstatě plní stejnou úlohu.
Nutno poznamenat, že v obou případech si ten composer.json respektive Cargo.toml poradí i se systémovými balíčky. V PHP/Composeru si specifikujete přesnou verzi php i požadované systémové extenze. V Rust/Cargo pro něco podobné slouží sekce [package.metadata.dependencies].
Jaké možnosti pro to má Python by mě zajímalo. Zdá se, že v tomto se to u Python ještě neusadilo.
23. 10. 2023, 13:17 editováno autorem komentáře
-
Já se popravdě taky nevyznám v tom proč se to tak táhne a v čem je ten spor. Zopakuji ti můj pohled na věc.
Jak předřečník dobře poznamenal, tak optional a development dependecies jsou něco jiného. Reagoval na moji poznámku, proč tyhle nástroje nepoužijí sekci optional dependecies v pyproject.toml, ale zavádějí vlastní -- což normálně jde a je to v pyproject.toml podoporováno.
Historicky se závislosti pro vývojáře buď nechávali v samostatném requirements.txt souboru nebo dávali do sekce optional s odpovidajícím klíčem např. dev nebo testing atd. To platí jak pro nový pyproject.toml, tak pro starší setup.py, kde se sekce jmenuje extras_require.
Pokud to je v optional pak to ale straší po instalaci v souboru PKG-INFO, což je asi proč to někomu vadí. Jinak pokud uživatel nenapíše pip install package[dev], pak se mu samozřejmě tyhle závislosti neinstalují, v tom problém není.
Oba přístupy, samostatný requirements.txt pro vývoj i sekce v extras_require jsou hojně používané.
Dle mého by se to mělo řešit na úrovni PSF a nikoliv aby to každý nástroj dělal podle svého. Ale v tom se snad shodneme všichni.
Kde se neshodneme asi je, že já tvrdím, že to prakticky nevadí to mít v extras_require.
Můj názor po diskuzi je, že radši dám vývojářské nástroje do samostatného requirements.txt a tím to vyřeším. Přeci jen vývojář si prostě napíše `pip install -r requirements.txt` a je hotovo. Jeden příkaz navíc, ale to je nic a je to čistší -- v tom souhlasím s předřečníkem.
Za mne vyřešeno.
26. 10. 2023, 11:53 editováno autorem komentáře
-
A BTW vubec neodpovidas na tu otazku.
Podle tebe nejde instalovat dependecies primo z pyproject.toml jo? Na tom trvas?namisto toho pises
"Nejde nahradit requirements.txt pomocí pyproject.toml. Pro jednoduché skripty chci definovat jenom pár dependencies typicky requests atp."
Coz je naprosto jine tema. Takze hrusky, jabka a mozna uz i svestky sem zavadis ty.22. 10. 2023, 10:53 editováno autorem komentáře
-
A BTW vubec neodpovidas na tu otazku.
Podle tebe nejde instalovat dependecies primo z pyproject.toml jo? Na tom trvas?Pokud vím, tak to stále nejde: https://github.com/pypa/pip/issues/11440 . Pozor nezaměňovat se sestavením celého projektu. Chtěl jsem jenom ukázat, jak je to celé nedotažené, nic víc nic míň.
-
Pavel TišnovskýZlatý podporovatel
je to divný a nestandardní, souhlas. Na druhou stranu to pypropect.toml zatím nemá specifikovaný rozumněji. Tak snad ten výše zmíněný tlak na komunitu...
-
Pavel TišnovskýZlatý podporovatel
souhlas s tím, že je to tlak na PSF, aby se některé věci v Pythonním ekosystému hnuly dopředu. Už je to zapotřebí, právě tady v podpoře "buildu" větších projektů.
-
Nemáte někdo řešení, jak nainstalovat balíčky z *.lock souborů (např. poetry.lock, pdm.lock, ...) bez instalace samotného správce balíčků?
Mým denním chlebem je tvorba python docker services. U docker kontejnérů se hraje na velikost, takže do něj instalovat celého správce balíčků (při počtu závislostí), je zbytečný luxus.
V tuto chvíli, to řeším tak, že v Dockerfile mám dva targety. První nainstaluje správce balíčků a potahá všechny závislosti do daného adresáře. Druhý target je z tohoto adresáře nainstaluje. Toto řešení je funkční, ale představoval bych si, že by to mohlo jít i snadněji. Nějaká jednoúčelová malá utilita, která by byla schopna instalovat věci z přiloženého *.lock souboru, ideálně i s kontrolou hashe.
Můj druhý dotaz, se týká binárních závislostí. Některé Python balíčky, vyžadují doinstalování binárních závislostí (deb, rpm, apk balíčků). Dost často se to člověk dozví jen z dokumentace. Pro jejich správu využívám "bindep" balíček. Existuje nějaká elegantnější možnost, jak tyto závislosti spravovat, ideálně přes pyproject.toml soubor?
ČLÁNKY DO MAILU