Pisi hata raporları arasında çözülmesi en karmaşık ve zaman alıcı olanlar, depo ve yerel makina arasında belirli adımlarla yapılan işlemler sonucunda istenmeyen
bazı durumlar ortaya çıkanlar.

Örneğin, “Makinamda A paketi yüklü idi, depo’da A paketi’nin güncellendiğini gördüm, ama önce güncellenmiş olan B paketini yükledim, ardından C paketini kaldırdım,ve A paketini güncellemek istediğimde pisi bana C paketi ile çakıştığını söyledi.” tarzında kullanıcılar tarafından bildirilen hatalar.

Genelde çözümü kolay hatalar tekrarlanabilir olanlardır. Yukardaki durumda kullanıcı’nın anlattıklarını bir şekilde tekrarlayabilirsem, oluşan hatayı görebilir ve düzeltebilirim. Ya da bu durumun bir hata olmadığını anlar ve bunun açıklamasını yapabilirim. Ancak bazı durumlarda bu hatayı tekrarlayabilmek hiç de kolay olmuyor. Depo ve yerel makina’daki paketler sürekli değişiyor ve güncelleniyor. Kullanıcı’nın karşılaştığı durumu tekrarlayabilmek için elle özel olarak hazırlanmış
paketler ile tek tek uğraşmak gerekiyor, ki bu da çok zaman alıcı bir iş.

Hafta sonu, bu işlemleri otomatikleştirebilmek ve sorunların daha iyi ifade edilebilmesini sağlamak amacıyla bir yapı hazırlamaya çalıştım. Ve ortaya pisi senaryo api’si çıktı. Daha emekleme aşamasında ama yararlı olacağını ve sorunların çözümünde oldukça hız kazandıracağını düşünüyorum. İhtiyaçlara göre de zamanla
gelişecektir.

Peki ne yapıyor bu senaryo apisi? Basitçe, sorununuzu anlatabilmek için paragraflar boyunca sisteminizde yaptıklarınızı ve gördüklerinizi anlatmak yerine, bu adımları script ile ifade ederek, beklediğiniz ve oluşan durumları 5-10 satır kodla anlatmanızı sağlıyor.

Basit bir örnek vermek gerekirse, 3465 nolu hata raporunu şu satırlarla ifade edebilirsiniz:

from pisi.scenarioapi.scenario import *

WORMUX = "w0rmux"

let_repo_had(WORMUX)
let_pisi_had(WORMUX)

def run():
    repo_version_bumped(WORMUX)
    repo_updated_index()
    pisi_reinstalled(WORMUX)

Kısaca anlatırsak, let_repo_had() depo’da bulunan paketleri, let_pisi_had() ise o an sisteminizde bulunan paketleri öncelikle tanımlamanızı sağlıyor. Her script’de bu tanımlamalar zorunlu olarak bulunmalı.

run() kısmında ise depo’da gerçekleşen ve sizin yaptığınız işlemleri adım adım sıralıyorsunuz. Bu script’de “wormux” paketinin depo’da güncellendiği, ardından depo index’i güncellenerek bu değişikliklerin ilan edildiği, sizin de kendi makinanızda bu işlemlerden sonra “wormux” paketi’nin makinanızdaki versiyonu’nu yeniden kurmak istediğiniz belirtilmiş. Script’i çalıştırdığınız zaman hata raporunda belirtilen çıktıyı aldığınızı göreceksiniz. Çalıştırmak için ise pisi’nin svn versiyonu elinizde olmalı. Svn pisi kök dizinin’de şu satırlar ile daha önce’den yazılmış bu script’i çalıştırabilirsiniz:

sudo scenarios/run.py bug3465

Script içerisinde mantıksal işleri mümkün olduğunca tek satırda okunup, anlaşılabilecek ve satır okunurken yine sanki mantıksal bir cümle okunuyormuş hissi verecek şekilde hazırlamaya çalıştım. Okunanın kod olarak değil, yapılan işlerin listesi olarak algılanmasını istedim.

Örnek olabilecek bir kaç satır:

        let_repo_had(A, with_dependencies(B, C))
        let_pisi_had(X, Y, Z)
        repo_version_bumped(A, with_removed_dependencies(B,C), with_added_conflicts(D))
        repo_version_bumped(A, with_removed_conflicts(D))
        repo_added_package(F, with_dependencies(G,H,I,J), with_conflicts(A))
        repo_version_bumped(F, with_removed_conflicts(A))
        repo_added_package(K, with_conflicts(F))
        repo_version_bumped(K, with_added_dependencies(X,Y,Z))
        repo_removed_package(A)
        pisi_installed(B,C,D)

Senaryo api’si henüz çok yeni. İhtiyaçlarını, yazılması gereken senaryolar belirleyecek. Ancak şimdilik görünen bazı eksiklikleri şunlar:

1. İskelet paket’e config dosyası eklenip, config senaryoları desteklenmeli.
2. Çoğu pisi işlemi os.system çağrıları ile yapılıyor ve pisi’nin ekstra opsiyonları kullanılmıyor. Örneğin conflict eden paketleri de birlikte yüklemek istiyorum diyemiyorsunuz.
3. Paket isimlerini dikkatli seçmek gerekiyor. Paket ismi ile aynı isimde çalıştırılabilir bir dosya “/usr/bin” altına paket kuruluduğu zaman yerleştiriliyor. Api’de şimdilik sabit olan “/usr/bin” klasörü altında varolan başka bir dosya ezilebilir.

Şimdilik sadece aklıma bunlar geliyor. Ancak dediğim gibi pisi’nin desteklenen hangi opsiyonlarını kullanacağını ve bu yapının gerçekten faydalı olup olmayacağını önümüze çıkacak senaryolar ve bu yapıya uygulanabilirlikleri belirleyecek.