Project ရေးပြီဆိုတာနဲ့ Package Manager ကိုပါလေ့လာပါ

Programming သင်ပြီဆိုရင်ကိုယ့် language နဲ့သက်ဆိုင်တဲ့ package manager နဲ့လည်း ရင်းနှီးကျွမ်းဝင်အောင် လုပ်သင့်တယ်။ နောက်ပိုင်းက IDE support ကောင်းလာတဲ့အတွက် code ရေးမယ်ဆိုရင် IDE ဖွင့်၊ project တန်းဆောက်၊ ဘာတခုမှ configure လုပ်စရာမလို၊ ရေးချင်တာသာ ကောက်ရေး၊ အကုန် import ပေးတဲ့အပြင် မြှားအစိမ်းလေး နှိပ်လိုက်တာနဲ့ code ကတခါတည်း run ပြီးသားဖြစ်သွားတော့ package manager တွေ configuration တွေကို သိပ်မထိဖြစ်ကြတော့ဘူး။

Package Manager တွေဘာကြောင့်လိုအပ်သလဲ။ Package Manager ဘာကြောင့်လိုအပ်သလဲဆိုရင် sourcecode file တွေကို သပ်သပ်ရပ်ရပ် ရွှေ့ပြောင်းနိုင်ဖို့လို့ ပြောရမယ်။ အဲဒါကြောင့် package manager တွေမှာ ဒီ ၃ ချက်ပါလေ့ရှိတယ်။

Packaging

နံပါတ် ၁ packaging လုပ်နိုင်စွမ်း။ java project ဒါမှမဟုတ် php project တခုရေးတယ် ထားပါတော့။ .java နဲ့ .php file တွေသူတို့ရဲ့ dependency တွေနဲ့ ပွစိတက်နေမယ်။ နောက်စက်တခုပေါ် ဒီ project ကြီးရွှေ့သွားဖို့ ဖြစ်လာရင် ရှိရှိသမျှ dependency တွေအကုန်လုံး (library တွေ၊ binary တွေစသဖြင့်) သယ်မသွားချင်ဘူး။ နောက်ပြီး sourcecode file တွေကိုလည်း တစုတစည်းတည်း standard format တခုနဲ့ ထုပ်ချင်တယ်ဆိုရင် ဒါ package manager လိုလာတဲ့အချိန်ပဲ။

Package manager တွေက ကိုယ့် project က depend လုပ်ထားရတဲ့ library တွေ binary တွေရဲ့ version ကိုအတိအကျ ချမှတ်ထားလို့ရစေပြီး ဘယ်နေရာ၊ ဘယ်စက်ပေါ်ကိုရောက်ရောက် အဲဒီ version အတိုင်း အတိအကျ download ပြန်ဆွဲပေးနိုင်တယ်။

ဘာကြောင့် dependency တွေသုံးတာလဲ။ ဥပမာ ကိုယ်က backend project တခုရေးနေတယ်ပဲ ဆိုပါတော့။ ကိုယ်အဓိကရေးချင်တာက user ဆီက request ဝင်လာရင် ဘယ်လို product တွေပြချင်တယ်၊ create လုပ်ချင်တယ်စသဖြင့်ပေါ့ ဟုတ်တယ်မလား။ request payload ကို byte stream ကနေ ဘယ်လို parse လုပ်ပြီး memory ပေါ်တင်မယ်ဆိုတာတွေကို project အသစ်လုပ်တိုင်းမှာ မရေးနေချင်ပါဘူး။

အဲဒီတော့ အဲဒီအပိုင်းအတွက်ကို သူများရေးထားပြီးသား library ကိုပဲ ယူသုံးလိုက်တယ်။ ဒါပေမယ့် သုံးတဲ့အခါမှာလည်း ကိုယ်သုံးလိုက်တဲ့ library ရဲ့ version တိတိကျကျ မှတ်ထားနိုင်ပြီး ဘယ်စက်ပေါ်ရောက်ရောက် အတိအကျ ပြန် fetch နိုင်မှ repeatable နဲ့ reliable build တွေလုပ်နိုင်မယ်။ အိမ်ကစက်မှာရေးတုန်းက version 1.0.8 ကိုသုံးပြီး အလုပ်ရောက်တော့ 2.0.2 ဖြစ်သွားရင် breaking change တွေပါလာမှာ ကျိန်းသေတယ်။

နောက်တခုက sourcecode file တွေကို single standard format နဲ့ထုပ်ပိုးနိုင်ရမယ်။ ဒါမှပဲ ရွှေ့ပြောင်းရလွယ်မယ်။ library တခုမှာ ဖိုင် ၂၀ ပါလို့ သူ့ကိုလိုအပ်တိုင်းမှာ ဖိုင်အခု ၂၀ ရှာထည့်ရမယ်ဆိုရင် အဲဒါသိပ်မဟုတ်တော့ဘူး။ pom.xml, go.mod, package.json စတဲ့ဖိုင်တွေမှာ လိုအပ်တဲ့ metadata နဲ့ depedency တွေကိုသတ်မှတ်ကြပြီး Java ရဲ့ jar file တွေ၊ Python ရဲ့ wheel တွေ၊ Rust ရဲ့ crate တွေ၊ Go ရဲ့ mod, JavaScript tarball နဲ့ php ရဲ့ phar စသဖြင့် ဒါတွေက language အလိုက် package manager တွေထုပ်ပိုးလိုက်တဲ့ artifact တွေဖြစ်တယ်။

Versioning

Package manager လုပ်ပေးတဲ့ ဒုတိယတခုက versioning ပါ။ အပေါ်မှာလည်း ထည့်ပြောသွားတယ်၊ ဘယ်စက်​ပေါ်ကိုရောက်ရောက် project တခုရဲ့ dependency တွေကိုလိုအပ်တဲ့ version အတိအကျ ပြန် fetch ပေးနိုင်တယ်ဆိုတာ။ အဲသလို လုပ်ပေးနိုင်တယ်ဆိုတာက package manager တွေမှာ သူတို့ package လုပ်လိုက်တဲ့ artifact တွေကို version သတ်မှတ်နိုင်သလို ဒီ artifact တွေကိုပြန် fetch တဲ့အခါမှာလည်း သတ်မှတ်ထားတဲ့ version ဟုတ်မဟုတ် အတည်ပြုနိုင်၊ စစ်ဆေးနိုင်အောင် ရေးထားလို့ဖြစ်တယ်။

Distributing

နောက်ဆုံးတချက်က distributing ပါ။ ဒါကတော့ သိသာပါတယ်။ Java ရဲ့ Maven, JavaScript ရဲ့ npm နဲ့ Rust Cargo, Python pip ဒါမှမဟုတ် php ရဲ့ composer ဒါတွေကိုသုံးပြီး dependency တွေ download ဆွဲတဲ့အခါ မိုးပေါ်က အလိုလိုကျလာတာမဟုတ်ပါဘူး။ package manager ကလိုအပ်တဲ့ package တွေကို package registry တွေဆီမှာ သွားရှာလာခဲ့တာပါ။

JavaScript အတွက် npm Registries, Java အတွက်ဆိုရင် Maven Central, Go မှာ Go proxy, Python Package Index နဲ့ Php ရဲ့ Packagist စတာတွေက package တွေကို တစုတစည်းတည်း သိမ်းထားတဲ့ Central Package Hub တွေပါပဲ။ package manager အနေနဲ့ package တခုကို သက်ဆိုင်ရာ registry တွေဆီ push တတ် သိမ်းတတ်ရမှာဖြစ်ပြီး လိုအပ်တဲ့ package တွေကိုလည်း သွားရှာပြီး fetch တတ်ရမှာဖြစ်တယ်။

တကယ်လို့ package.json ကိုမကလိရဲသေးဘူး။ pom.xml ကိုကြည့်ပြီး အခုထိ ကြောက်နေတုန်းပဲ။ requirements.txt ဒါမှမဟုတ် go.mod ထဲဆယ်ခါတခါတောင် ဝင်မကြည့်ဖြစ်ပါဘူးဆိုရင် ကိုယ်သုံးနေတဲ့ package manager ကိုလေ့လာဖြစ်ဖို့ ဒီနေ့ပဲ စလုပ်ပါတော့။