Python - Google API Client - conflict

Szkriptek: Python, Perl, Bash, ...

Sziasztok,

Generált a Copilot egy Python szkriptet. 

Már az első sor hibára fut:

from googleapiclient.discovery import build

A hibaüzenet:

ImportError: Module use of python38.dll conflicts with this version of Python.

pip-pel telepítettem a modult, sikeresen le is futott. 

Próbáltam már ezerféleképpen, az istennek nem akar működni.

python --version
Python 3.13.1

pip --version
pip 24.3.1

( eff | 2025. 01. 20., h – 13:06 )

Szerkesztve: 2025. 01. 20., h – 13:07

Windows, es tobb python telepites, ugy tunik valami miatt a 3.13-as python indulasnal megprobalja behuzni a a 3.8-as python dll-t.

Sok sikert a path-ok rendberakasahoz, ez a python egyik nagy rakfeneje barmilyen rendszeren.

szerk: pythonpath, sys.path, a kulcsszavak a debughoz.

( kallaics | 2025. 01. 20., h – 13:57 )

Szerkesztve: 2025. 01. 20., h – 14:02

Konkrét kódrészlet nélkül nehéz építő jelleggel mondani bármit is, de megpróbálom.

Javaslom olvass utána "Python virtual environment"-nek és abba tedd fel a függőségeket, majd próbáld meg futtatni a kódot. Elvileg így mennie kéne.

Nalam python 3.6-tol 3.12-ig kezdve minden fent van es millio virtenv-em van. Igazabol (a nem szeretett) Makefile-jaim csinaljak a dolgukat a programkonyvtarakban ha esetleg koltozni kellene egy masik gepre is :D 

Ezt belerakja az ember bermelyik progijanak konyvtaraba aztan mehet a make <parameterek beallitasa> es kesz is van

 

SHELL     = /bin/bash

# variables
APP      ?= application
PYVER    ?= python3.7
VENV_DIR ?= $HOME/virtualenvs/${APP} 

.PHONY: all venv

all: venv

venv: $(VENV_DIR)/bin/activate

$(VENV_DIR)/bin/activate: requirements.txt
	python -m venv -p $(PYVER) $(VENV_DIR)
	source $(VENV_DIR)/bin/activate ; pip install -Ur requirements.txt

Aztan meghivod, hogy make PYVER=python3.12 VENV_DIR=<ha mashova akarod es nem a homeodba> APP=<csak azert hogy legyen valami pofja hiuvjuk a dirt az app neven>, pl.: make APP=janitor PYVER=3.8

De ez csak az en szarsagom, meg windowsra at kellene irni. De gondolom van aki ezt siman megcsinalja maven-ben is :D

Ja, nekem semmi bajom a makefile-al (illetve de, gyűlölöm, mint a szart, de tisztában vagyok vele, hogy ez egyszocprob :D), csak erre a konkrétra pont van egyébként kész eszköz, ami kb ugyanezt tudja, hogy "szabványos". Illetve pluszban hozza, hogy a függőségek verziói sem esetlegesek, attól függően, hogy-hogyan csinálsz CI-t, van haszna/van kicsit útban :)

De ezzel sincs emmi baj egyébként :)

hat ize ott a requirements.txt pont azert ami pont lefgedi a pontos verziokat es nem esetlegesek

de persze ez nem CI-ra van, hanem magan projektekre. Azert is hoztam peldanak, hogy kexdetben ez jo is ha csak egyedul bohockodik az ember. Ertelem szeruen itt nem tudom konnyen cserelni az egyes verziokat (de, tudom, hiszen egy masik requirements.txt-t is beadhatok neki, de az azert nem egy automatozalt megoldas, igy CI-ra tenyleg nem jo)

hat ize ott a requirements.txt pont azert ami pont lefgedi a pontos verziokat es nem esetlegesek

Őőő, nem :)

Mármint a requirements csak a közvetlen függőségeket pineli, amit azok miatt felráncigál a pip, azok ahogy épp puffannak. A pipenv meg csinál egy lockfilet, benne a mindennel is, ami hasznos, ha tényleg konzisztens környezetet akarsz csinálni. (Ha meg csak akármi kell, akkor ezt a részét le lehet szarni)

Egyébként értem, valóban jó ez, és kb ennyi, csak mondtam, hogy ezt egyébként pont van tool, ami csinálja, még makefilet se kell másolgatni, meg semmi.

egyetertek. felreertettelek, meg en altalaban nem nagy projekteket csinalok magamnak csak icipici rest API-kat max. Ahhoz a requirements.txt pont mindent tartlamaz nincs olyan amit azokhoz kepest huzna fel. szoval nincs olyan hogy "azure" module aminek van 100+ fuggosege, amit magaval rant

Hozzateszem, hogy sosem dolgoztam programozokent, szoval az olyan komoly dolgokat mint a pipenv meg maven, meg a tobbi meghagyom azoknak akik ertenek is hozza es nem olyan szakbarbarok, mint en. Makefile is csak azert van, mert meg 1999 tajekan azzal automatizaltam sime bash scriptek helyett egy csomo mindent es azota cipelem magammal ezt a terhet, mint egy nem mulo "betegseget" :D

( bazso | 2025. 01. 20., h – 14:36 )

Kezdő python koromban egy ilyen hiba javításának a végére megtanultam, hogy egy fejlesztés függőségei miatt véletlenül sem cseszünk bele az oprendszer csomagjaiba (minden más törik). Virtualenv és hasonszőrű haverjai a te barátaid, mindegy, csak legyen elválasztva a környezet dolgaitól