benim hatam sayilir. pisi-cli komutlarina specific option'lar icin
 ne yaptigim tam anlasilmamis sanirim. olay su. her komutun ayri
 bir option'i var. bunu optparse'la yapabilmek icin once komutu okuyup
 sonra parser'i construct ediyor. ilk komutu okumayi da gene optparse'la
 yaptim ama daha kolay bir yolunu biliyorsaniz yapin (bu daha basit
 o acidan). bir de svn'de oldugu
 gibi common option'larin specific option'lardan once gelmesi de enforce
 edilebilir. su anda enforce edilmiyor ama oyle olmassa sicabilir.

 nasil calistigini gormek icin:

 pisi-cli --test remove x
 pisi-cli --test build x

birincisinde remove'a ozel --test option'i taninir. ikincisinde build'in
oyle bir option'i olmadigi icin veryansin eder.

* help'ler koy komutlar icin ayri ayri
* nedir

* eger yeniden kurumsa, eski paketi once remove edelim, aha!
* upgrade mi downgrade mi info'lar confirm'ler cabasi
* dunyanin en dandik installation seysi degil artik :) ama daha calismadi

* files'i da oku, installer'da
* gene installer'da files ve metadata'nin varligini test et
* duzelt: eger packagedb'de bilgisi yoksa dosyanin icinden sok

--no commit message

ActionsAPI içinde düzenlemeler, dosed native python'a çevrildi. Sonuç olarak bash içinde RegularExpr. magic var kendileri de birazdan commit edilecek. Bu regular exp. denen illet acayip birşey...

Diğer bölümleri yalnızca comment-out ettim.

Burada bir-iki düzenleme daha gerekebilir...

 bir goz atin commentlere..

bikaç gerek ile neden pisi için maddeler.

  - bunun icin iki kere parse etmek gerekiyor, ayrintilar kod'da
  - bir komut icin komut_opts() diye birsey yaziyorsunuz oluyor optionlar
  - index'i de koy
  - biraz duzenle optimize et
  - pisi-index'i cikar

--no commit message

--no commit message

--no commit message

- pisi-cli'i refactor ettim.

ortalığa biraz temizlik gerekecek, yapacağız tabii biz de gerekeni :)