[Gelistirici] pisi dosya işleri

[Eray Ozkural]

[bu uzun bir mail oldu, basit bir konu hakkinda uzun bir yazi. kafam 
karisikmis izlenimi yaratmasin. ozet geciyorum o yuzden.]

ozet: modulerlik fikrini sevdim, ama ilk etapta aynen actionsapi'da 
yaptigimiz gibi monolithic bicimde yapalim. bu guzel fikrini de 
iyilestirme olarak girelim. bence 1.1 sonrasi icin dusunelim derim. 
simdi tasarim yapalim degistirelim zamani da degil bence. KISS tarzi 
cozumler yapabiliriz, temiz yapariz pislemeyiz ortaliga.

Gürer Özen wrote On 14-06-2006 21:05:
> Çarşamba 14 Haziran 2006 19:15 tarihinde, Eray Ozkural şunları yazmıştı: 
>   
>> gurer, ben pisi'nin taban calisma icin comar bagimliligini kaldirmak
>> istiyorum, bunu gereksiz buldum.
>>     
>
> Neden? Çomar 40kb lik, extra dependency getirmeyen bir paket.
>
>   
cunku gorunen o ki (varsa yanlis lutfen duzeltiniz) comar'in 
ozelliklerine ihtiyac duyulmuyor pisi'nin taban seviyede calismasi icin 
(install/remove) ve bu diger dagitimlarda/platformlarda kullanilmasini 
vs. kolaylastiracak. comar olmasa da her zaman postinstall/preremove'lar 
calisacak. ama comar destegine tabii ki dokunmayacagim ve hicbir spec 
degisikligi olmayacak, bunu bir wishlist'de ozetlemistim. (optimizasyon 
yani) sadece illa-ister bagimliligindan konusuyorum. (ideal olarak ne 
pisi comar'a ne de comar pisi'ye bagimli olmali temel calisma icin 
bence, su andaki durumdan farkli  bir idealden bahsediyorum.)

>> bunlarin hepsi pisi icinde cok basit bicimlerde halledilebilir.
>> gerekirse bir tag ekleyebiliriz pspec'e o kadar basit. bunu pisi
>> icerisinde yaparsak daha iyi olur. kulagi ayakla gostermeye gerek yok.
>>     
>
> O kadar basit değil, mesela apache yada daha başka bir programın modülleri 
> falan için pisi içine kod mu ekleyeceksin? Bu işleri paketin post 
> install'unda yapmak da güzel bir çözüm değil, jenerik işleri 50 tane pakette 
> kopyalamak gereksiz kod duplication.
>
> Halihazırda çomar bütün gerekenleri hallediyor zaten, 3 satırlık ekle sorunu 
> çözmek varken, pisiyi boyunu aşan bir program haline getirmenin anlamı ne?
>   

bence nereye koydugumuz su etapta cok farketmez. (aciklama asagida)

bu tur desteklerin moduler olmasi hosuma gider. modulerlik gayet guzel 
bir fikir. ama burada modulerligin comar tarafindan saglanmasi bana 
guzel gozukmuyor. (her moduler sey comarla mi yapilmali?) pisi'nin 
icerisine ozel durum hep sokuyoruz ve sokacagiz, orada da bir yanlislik 
var gibi gozukuyor, ayrica bunlar ozel degil bircok paketin genelinde. 
(actionsapi'daki perl destegi ne kadar genelse, dosya tipine gore perl 
kurulumu destegi de o kadar geneldir)

kisacasi dosya tipi <--> dosya kurulumu bagintisi bence pisi'nin 
gorevidir, orada bir plug-in sistemi olacaksa da onu pisi halledebilir. 
ama ben plug-in'in neden gerektigini gormuyorum, file type pisi'nin isi. 
Eger bu associationlarin sayisi belli bir miktari asarsa basit bir 
plugin sistemi yapabiliriz. (Comar da kullanilabilir dedigin gibi) 
Dedigine benzer bicimde (ama sanirim tam ayni olmuyor), install-info ile 
info tipini iliskilendirme ve fonksiyonu texinfo tarafindan kurulursa 
gayet shik olur, ona katiliyorum. Calisma bicimi de, iliskilendirmeden 
fonksiyon bakilir, o dosya tipi icin gereken fonksiyon cagirilabilir. 
Burasi tamam.

Tamam olmayan kismi:

files.xml pisi'nin inceledigi birsey, ona gore karar verip iki tane 
fonksiyon cagirmak icin yepyeni seyler gerekmez. zaten files.xml'i 
okuyup inceliyoruz code'da, o yuzden cok basit. file type'a bakacaksak o 
da zaten tamamen pisi'nin icinde ve sorumlulugunda.

pisi'nin icinde zaten perl vs. gibi degisik seylerin build safhasiyla 
ilgili tonla destek var, postinstall/preremove icin de destek olabilir. 
bu gayet normal, bir celiski yok. library'leri vs. de pisi'nin icinde 
hallediyoruz ve bunda da yanlis bir taraf yok. library install 
etmek,info doc'u install etmek vs. bunlarin hepsi ayni tur isler. 
installation'la ilgili butun common code pisi'nin icine gidiyor. doh. :) 
atomicoperations.py'e birkac satir yazacagiz bitecek, bu mail'leri 
yazmaktan daha kolay olur diyorum.

bu az cok debian'daki debhelper vs. gibi seylerin cok daha temiz bicimde 
yapilmasi olur. (cunku standard olacak)

mailindeki atmosferin aksine comarda yapmak sadece code size'i arttirir, 
azaltmaz. bu yuzden de daha kolay degil gibi gozuktu bana, comar'in 
pisi'nin ic yapisi (files.xml ya da baska herhangi bir icyapi) hakkinda 
hicbir sey bilmesi gerekmiyor zaten, ve bilmemesi gerekir diye dusunuyorum.

bu yuzden bana yapay bir fiziksel modul ayrimi olarak gozuktu simdilik 
(sadece buradaki oneri bu sekliyle). comar'i gereksiz seylerle 
sisirmeyelim. :P comar'in once comarize olmamis paketlerle ilgilenmesi 
gerek bence :) saka bir yana, bunu iyilestirme olarak girelim, ve lutfen 
irdelemeye devam edelim. ben mailini kopyalayip giriyorum iyilestirme 
istegini.

saygilar,

--
eray