Mops نسخه ۳ ساخت Motoko را به یک آرتیفکت ثبت‌شده تبدیل می‌کند

نسخه ۳ Mops که در ۲۰ اوت منتشر شد، شیوه تعریف build در پروژه‌های Motoko را تغییر می‌دهد. این package manager اکنون نسخه کامپایلر و ابزارهای پشتیبان مورد استفاده پروژه را مدیریت می‌کند و یکپارچگی با dfx را کنار گذاشته است.

تغییر اصلی در بخش [toolchain] فایل mops.toml قرار دارد. پروژه‌ها می‌توانند نسخه‌های moc، PocketIC، Wasmtime، Lintoko و wasm-opt متعلق به Binaryen را pin کنند. دستورهایی که کامپایل انجام می‌دهند به نسخه مشخص Motoko نیاز دارند و آزمایش‌های replica و بررسی‌های مرتبط نیز به نسخه مشخص PocketIC نیازمندند. اگر ابزارها pin نشده باشند، Mops خطا می‌دهد و به‌صورت بی‌صدا یک مقدار پیش‌فرض انتخاب نمی‌کند.

اهمیت این تغییر در آن است که درخت کد منبع، تمام ورودی build یک canister نیست. رفتار کامپایلر، replica و بهینه‌سازی Wasm همگی می‌توانند روی آرتیفکت نهایی اثر بگذارند. طبق توضیح Mops، در نسخه‌های قبلی نبودن pin برای wasm-opt می‌توانست در زمان build یک جست‌وجوی شبکه انجام دهد، فایل manifest را بازنویسی کند و بین انتشارهای مختلف Binaryen خروجی‌های متفاوت بسازد. در نسخه ۳، optimizer باید pin شود و شکست بهینه‌سازی build را متوقف می‌کند، نه اینکه بی‌سروصدا یک module بهینه‌نشده تحویل دهد.

این release مرز روشن‌تری برای CI ایجاد می‌کند. دستورهای معمولی mops.lock را نگهداری می‌کنند؛ CI می‌تواند از --locked استفاده کند که lockfile به‌روز را الزامی می‌کند و هرگز آن را تغییر نمی‌دهد. lockfile نسخه‌های resolveشده، hash هر فایل از packageهای registry، و commit به‌همراه hash محتوایی وابستگی‌های GitHub را ثبت می‌کند. بنابراین refای مانند #main یک‌بار resolve و سپس با commit دریافت می‌شود و جابه‌جایی branch یا tag نمی‌تواند بی‌سروصدا build قفل‌شده را تغییر دهد.

مدل امنیتی به‌صورت عمدی دو بخش دارد. فایل‌های package هنگام دریافت بررسی می‌شوند تا دانلود خراب وارد cache نشود. بررسی کامل فایل‌هایی که از قبل روی دیسک هستند اکنون با دستور صریح mops verify انجام می‌شود. در نتیجه توسعه‌دهندگان باید lockfile commitشده را یک ورودی قابل بازبینی برای build بدانند و هرجا جلوگیری از mutation لازم است، در CI از --locked استفاده کنند.

بخش ناسازگارکننده، مرز dfx است. Mops دیگر mops toolchain init یا moc-wrapper را ارائه نمی‌کند و متغیر DFX_MOC_PATH را نیز در GitHub Actions نمی‌نویسد. بنابراین ممکن است workflow همچنان موفق بماند، در حالی که mops check با یک کامپایلر و dfx build با کامپایلری دیگر اجرا می‌شود. تیم‌هایی که روی dfx می‌مانند باید مسیر کامپایلر را خودشان تنظیم و هماهنگ نگه دارند؛ مسیر پشتیبانی‌شده برای ICP، recipeای است که mops build را فراخوانی می‌کند.

یک نکته مهاجرتی ممکن است شبیه regression دیده شود: baselineهای benchmark به این دلیل تغییر می‌کنند که Mops نسخه ۳ در دستورهای مربوط به replica همیشه از PocketIC استفاده می‌کند. نخستین مقایسه ممکن است فقط به‌خاطر تغییر ابزار اندازه‌گیری، تعداد instruction یا heap متفاوتی نشان دهد. ثبت دوباره baseline بخشی از مهاجرت است و به‌تنهایی نشانه کندتر شدن canister نیست.

برای تیم‌های ICP، فهرست عملی کوتاه است: toolchain را pin کنید، mops.lock را commit کنید، در jobهای CI قابل‌بازتولید --locked اضافه کنید، تنظیمات DFX_MOC_PATH را بررسی کنید و پس از خروج از replica ضمنی dfx، baselineهای benchmark را دوباره ثبت کنید. درس گسترده‌تر این است که reproducibility اکنون ابزارهای تولید و اندازه‌گیری canister را نیز شامل می‌شود، نه فقط وابستگی‌های Motoko را که import می‌کند.

ملاحظه ویرایشی: ارقام نصب نقل‌شده در اطلاعیه release، گزارش maintainers هستند و در این مقاله به‌صورت مستقل بازتولید نشده‌اند. مستندات Mops نیز می‌گوید بهبود سرعت lockfile بیشتر زمانی دیده می‌شود که packageها از قبل در cache موجود نباشند.