path.txt

PATH mevzusu cogu programci icin tam anlasilmayan ve her programlama dilinde farkli cozulen bir sorun
ve cok vakit kaybina neden oluyor
peki virtualenv ne demek ona deginelim, aslinda virtualenv'in yaptigi su. Senin PATH'inin basina virtualenv klasorundeki bin klasorunu koyuyor
yaptigi temelde bu
virtualenv calistirmadan once PATH=/usr/bin:/bin diyelim
bu durumda ahmet yazarsan ahmet binary'sini o klasorlerde arayacak
virtualenv'i aktive ettiginde yaptigi aslinda su
PATH=myenv/bin;/usr/bin:/bin
dolayisiyla virtualenv cok da bir sey yapmiyor
virtualenv'i aktiflestirmeden dogrudan o venv icindeki python'u da calistirirsan ayni kapiya cikar
virtualenv'i deaktive etmek de PATH'ini onceki haline geri getirir.
bir de PYTHONPATH mevzusu var
bu da import ahmet dediginde nereye bakacagi
burada da aslinda temelde sunu yapiyor
oncelikle buldugu python binary'sinin bir ust klasorune gidiyor
oradan da lib/python3.7/site-packages klasorune gidiyor
dolayisiyla ilk oraya bakiyor
ama sen PYTHONPATH'i elle degistirirsen ilk oraya degil de buraya bak dedirtebilirsin (ama genelde boyle bir sey cok yapilmaz)
pip install dedigin zaman ne yapiyor peki?
hangi pip olduguna gore degisir
pip'i nerede calistiriyorsun? terminal'de
o anki terminal'indeki path'te hangi klasorde pip'i buldu?
iste bu da yine virtualenv'in aktif olmasina gore farkli farkli yerlerden bulunabilir
ama diyelim ki venv aktif
o zaman python neredeyse o pip de orada
o zaman pip install diyince
yine ilgili lib klasorune yukleyecektir
o zaman, pip aslinda alti ustu bir download islemi yapiyor, pip olmasa elle paketi indirip oraya koyabilirdin
ya da ayri bir klasor acardin, oraya indirirdin
zaten o yuzden easy_install vb gibi eski turevleri de var
tabii o kadar basit degil, mesela numpy gibi kutuphanelerin bazi paketleri c gibi dillerde yazilmistir, bunlarin compile edilmesi gerekir.
ama genelde artik bunlar precompiled wheel seklinde iniyor,
tekrar compile etmiyorsun senin isletim sistemin icin onceden compile edildiyse
dolayisiyla ozellikle mac, ubuntu gibi sistemlerde bunlari direk compile binary olarak indirip site-packages'a koyar.
diger dillerde de PATH mevzusu benzer
mesela node'da npm install dersen bu sefer o da mevcut klasordeki node_modules icine koyar paketlerini
executable binary'ler de node_modules/.bin klasorune konur
dolayisiyla `npm install mybinary` dedikten sonra
`mybinary` dersen o program calismaz
cunku node_modules/.bin klasoru path'te degildir
o durumda da ya node_modules/.bin/mybinary diye tum path'i verirsin
ya da npx mybinary dersen npx adli arac gider bu mybinary exe'sini node_modules/.bin'de arar oradan calistirir
dolayisiyla aslinda path mevzusu genelde binary path'ler ve kutuphane path'leri seklinde iki kategoride her dilde benzer sekilde isler.
bir de c gibi compiled dillerde headerlar konumuna bakilan include path'lerin belirlenmesi vardir.
bircok programci icin butun bu tarz islemler bir bas belasi ve cogu zaman anlasilmiyor
nedeni de bash, fish, zsh gibi shell'lerin bunlari kullanicidan gizleyerek yapmasidir
burada debugging icin yardimci olacak arac da aslinda env ya da printenv gibi araclar
bir araci calistirmadan once env yazip calistirdiktan sonra env yazarsaniz aslinda o aracin ne yaptigini anlayabilirsiniz
bir nevi global degiskenler degismekte ve bircok kisi burada sorun yasamakta. ama anlayinca aslinda basit.
butun bunlar icin bir rosettastone tarzi bir yazi yazmak gerek aslinda.

iste mesela ruby icin: "bundle exec rails"
yine ayni mantik
rails binary'sini calistirmadan once bundle exec gecici olarak path'e rails'in oldugu klasoru koyuyor
ya da son zamanlarda python'da cikan pipenv
pipenv python diyince bu sefer yine once python'in oldugu klasoru ekliyor
sonra calistiriyor
ama islem bitince hicbir iz kalmiyor
pipenv ile normal virtualenv'in farki bu aslinda.