ALLP Manager دستور allp · ویکی

ALLP Manager یک هماهنگ‌کننده شفاف برای Package Managerهای نصب‌شده روی سیستم است. یک رابط فرمان واحد می‌دهد، اما منبع نرم‌افزار، دستور Native و سطح دسترسی لازم را از کاربر پنهان نمی‌کند.

نقشه مستندات

مدل ذهنی پروژه

درخواست → کشف مدیرهای نصب‌شده → پرس‌وجو از Backendهای توانمند
       → نمایش انتخاب‌ها → ساخت Plan تغییرناپذیر
       → نمایش دستور دقیق → تأیید → اجرای مستقیم

ALLP Manager Dependency Resolver یا دیتابیس پکیج مستقل نیست. ابزارهای Native همچنان منبع حقیقت باقی می‌مانند.

قول امنیتی ALLP Manager

• فرمان‌ها به شکل Program و Argv نگه‌داری می‌شوند، نه رشته Shell.
• هر تغییر قبل از اجرا برنامه‌ریزی و نمایش داده می‌شود.
• --dry-run هیچ تغییری ایجاد نمی‌کند و sudo را فراخوانی نمی‌کند.
• --yes فقط تأیید نهایی ALLP Manager را رد می‌کند و Flagهای Native را کورکورانه اضافه نمی‌کند.
• دسترسی Root فقط به Child لازم داده می‌شود؛ ابزارهای User-scoped در Context کاربر اصلی می‌مانند.
• پروژه Telemetry ندارد و Credential ذخیره نمی‌کند.

برای قراردادهای دقیق مهندسی به معماری، رفتار فرمان‌ها، قرارداد Backend، Schema خروجی JSON و مدل امنیت مراجعه کنید.

پیش‌نیازها

• Linux برای عملیات بالغ‌تر؛ Homebrew در macOS هنوز Experimental است.
• حداقل یک Package Manager پشتیبانی‌شده روی سیستم.
• Rust 1.74 یا جدیدتر، فقط برای Build از سورس.
• sudo فقط وقتی Child Process انتخاب‌شده واقعاً Root می‌خواهد.

⚠️ اگر Rust و Cargo ندارید، ابتدا آن‌ها را نصب کنید. Git، Make و کامپایلر و لینکِر C هم لازم‌اند. از راهنمای رسمی نصب Rust استفاده کنید، ترمینال را دوباره باز کنید و سپس بررسی کنید:

rustc --version
cargo --version

نصب از سورس

git clone https://github.com/allp-manager/allp-manager.git
cd allp-manager
make install

دستور make install برنامه را می‌سازد و با sudo در /usr/local/bin/allp نصب می‌کند.

نصب کاربری بدون sudo

برای نصب فقط برای کاربر خودتان، در همان پوشهٔ مخزن به‌جای make install این دستورها را اجرا کنید:

make install-user
export PATH="$HOME/.local/bin:$PATH"
allp --version

مقصد نصب ~/.local/bin/allp است. دستور PATH بالا برای ترمینال فعلی است؛ برای ترمینال‌های بعدی هم این خط را در فایل تنظیمات Shell خود اضافه کنید.

Termux در اندروید

Termux فعلاً محیط پشتیبانی‌شدهٔ ALLP Manager نیست. دستور make install از sudo استفاده می‌کند و در /usr/local/bin نصب می‌کند؛ این روش با Termux معمولی سازگار نیست. دستور make install-user در مرحلهٔ نصب به sudo نیاز ندارد، اما عملیات مدیریت پکیج را با Termux سازگار نمی‌کند: عملیات تغییردهندهٔ APT در ALLP Manager همچنان دسترسی روت می‌خواهند. پشتیبانی بومی Termux به سازگاری جداگانهٔ اجرا، مسیرها و سطح دسترسی نیاز دارد. تا پیاده‌سازی و آزمایش این پشتیبانی، پکیج‌های Termux را با دستور بومی pkg مدیریت کنید.

اولین اجرای امن

allp doctor
allp detect --verbose
allp search git
allp install git --from apt --dry-run
allp install git --from apt

قبل از فرمان آخر، Backend، Argv و سطح دسترسی Plan را بخوانید. با --scope apps، --scope dev یا --scope all محدوده را صریح کنید؛ وقتی منبع مهم است همیشه --from <backend> بدهید.

تفاوت Update و Upgrade

update معمولاً Metadata را تازه می‌کند و upgrade نرم‌افزارهای نصب‌شده را ارتقا می‌دهد. معنای دقیق را هر Backend تعیین می‌کند و ALLP Manager آن را قبل از اجرا نشان می‌دهد.

allp update --dry-run
allp upgrade --dry-run
allp update
allp upgrade

در خطای Lock هیچ‌وقت فایل Lock مدیر Native را حذف نکنید؛ منتظر Process مالک بمانید یا آن را به شکل امن بررسی کنید.

عملیات Package در Linux سطح اصلی محصول است. Homebrew در macOS هنوز Experimental است. Windows ساخت، Diagnostics، انتخاب Release Target و جایگزینی Deferred و تأییدشده را دارد، ولی Backendهای Linux-only مثل Snap/Flatpak را اعلام نمی‌کند.

ALLP Manager خانواده Debian، Red Hat/Fedora، Arch، SUSE و Alpine و همچنین Bazzite را به‌عنوان Host مبتنی بر Image می‌شناسد. معماری، libc، وضعیت WSL/Container و مسیرهای داده Platform را نیز ثبت می‌کند.

⚠️ اگر Rust و Cargo ندارید، ابتدا آن‌ها را نصب کنید. Git، Make و کامپایلر و لینکِر C هم لازم‌اند. از راهنمای رسمی نصب Rust استفاده کنید، ترمینال را دوباره باز کنید و سپس بررسی کنید:

rustc --version
cargo --version

نصب از سورس

git clone https://github.com/allp-manager/allp-manager.git
cd allp-manager
make install

دستور make install برنامه را می‌سازد و با sudo در /usr/local/bin/allp نصب می‌کند.

نصب کاربری بدون sudo

برای نصب فقط برای کاربر خودتان، در همان پوشهٔ مخزن به‌جای make install این دستورها را اجرا کنید:

make install-user
export PATH="$HOME/.local/bin:$PATH"
allp --version

مقصد نصب ~/.local/bin/allp است. دستور PATH بالا برای ترمینال فعلی است؛ برای ترمینال‌های بعدی هم این خط را در فایل تنظیمات Shell خود اضافه کنید.

Termux در اندروید

Termux فعلاً محیط پشتیبانی‌شدهٔ ALLP Manager نیست. دستور make install از sudo استفاده می‌کند و در /usr/local/bin نصب می‌کند؛ این روش با Termux معمولی سازگار نیست. دستور make install-user در مرحلهٔ نصب به sudo نیاز ندارد، اما عملیات مدیریت پکیج را با Termux سازگار نمی‌کند: عملیات تغییردهندهٔ APT در ALLP Manager همچنان دسترسی روت می‌خواهند. پشتیبانی بومی Termux به سازگاری جداگانهٔ اجرا، مسیرها و سطح دسترسی نیاز دارد. تا پیاده‌سازی و آزمایش این پشتیبانی، پکیج‌های Termux را با دستور بومی pkg مدیریت کنید.

command -v allp
allp --version --verbose
make install-check

اگر Copy اشتباه Resolve شد، PATH را اصلاح و در bash از hash -r یا در zsh از rehash استفاده کنید. Binary متعلق به dpkg/rpm/Pacman توسط همان منبع مدیریت می‌شود.

این راهنما مطابق استفاده واقعی پیش می‌رود: شناخت سیستم، Search، انتخاب منبع معتبر، دیدن Plan، اجرای تغییر و بررسی نتیجه.

۱. سیستم را بشناسید

allp --version --verbose
allp doctor
allp detect --verbose

doctor سیستم‌عامل، خانواده توزیع، معماری/libc، Context کاربر و sudo، مالکیت نصب ALLP Manager، مسیرهای داده، Release Target و آمادگی Backendها را توضیح می‌دهد. detect وضعیت و Capability همه Backendها را نشان می‌دهد. ابتدا علت FoundButUnavailable یا FoundButUnconfigured را برطرف کنید.

۲. در Scope درست جست‌وجو کنید

allp search firefox --scope apps
allp search black --scope dev
allp search git --scope all
allp search pycharm --from snap

• apps: پکیج سیستمی، اپ عمومی و Homebrew.
• dev: اکوسیستم Python، Node و Rust/Cargo.
• all: تمام منابع مجاز.
• --from: یک Backend یا Installer دقیق مثل apt، flatpak، snap، homebrew، pipx، pnpm یا cargo.

نتیجه‌ها Exact، Related و Fuzzy هستند. --exact فقط تطبیق دقیق و --all نتیجه Fuzzy ضعیف را هم نشان می‌دهد. هم‌نامی، برابری پکیج‌ها را اثبات نمی‌کند.

۳. قبل از نصب بررسی کنید

allp info firefox
allp info firefox --from flatpak --full
allp info git --from apt --raw
allp install git --from apt --dry-run

خروجی عادی info خلاصه و Curated است؛ --full Metadata نرمال بیشتر و --raw خروجی Native می‌دهد. Dry Run تمام Discovery، Resolve و Plan را انجام می‌دهد، ولی هیچ تغییری ایجاد نمی‌کند و sudo را اجرا نمی‌کند.

۴. نصب یا حذف کنید

allp install git --from apt
allp install org.mozilla.firefox --from flatpak
allp install black --from pipx
allp install typescript --from pnpm
allp install ripgrep --from cargo

allp remove git --from apt --dry-run
allp remove git --from apt

Package ID، Source، Scope، Argv دقیق Native و سطح دسترسی را بخوانید. اگر منبع مبهم است آن را صریح انتخاب کنید؛ --yes برای شما منبع انتخاب نمی‌کند. نصب پیش‌نیاز یا افزودن Remote یک Plan جداگانه است.

۵. نرم‌افزارهای نصب‌شده را ببینید

allp list
allp list --from apt --filter git
allp list --from flatpak --limit 50 --no-pager
allp list --json

Filter قبل از Limit اعمال می‌شود. خروجی بلند با Pager مستقیم نمایش داده می‌شود و Pipeline مخفی ندارد.

۶. سیستم را نگهداری کنید

allp update --dry-run
allp upgrade --dry-run
allp update
allp upgrade

Update معمولاً Metadata را تازه می‌کند؛ Upgrade نرم‌افزار نصب‌شده را تغییر می‌دهد. Plan کل Batch قبل از تأیید ساخته می‌شود، سپس عملیات ترتیبی اجرا و بعد از Failure یک Backend ادامه پیدا می‌کند. Exit Code شماره ۸ یعنی شکست جزئی.

allp update --from apt --skip-self-update
allp upgrade --from flatpak
allp update --scope dev --target tools --dry-run
allp upgrade --scope dev --target global --dry-run
allp update --no-tui

۷. مجموعه ابزار را بازسازی کنید

allp profile save workstation
allp profile export workstation workstation.toml
# فایل TOML را در مقصد بازبینی کنید
allp profile import workstation.toml --name new-machine
allp profile install new-machine --dry-run
allp profile install new-machine

Profile هویت Backend را حفظ می‌کند. Version فقط مشاهده Inventory است و Pin نیست؛ Inventory سیستمی ممکن است Dependencyها را هم داشته باشد.

۸. در CI یا Script استفاده کنید

allp search git --from apt --json
allp update --dry-run --json
allp install git --from apt --no-interactive --yes

schema_version مورد انتظار، complete و issues را بررسی و Exit Codeها را مدیریت کنید. Mutation واقعی باید بعد از Dry Run بازبینی‌شده باشد. Bootstrap بدون تعامل علاوه بر --yes به --allow-bootstrap نیاز دارد.

عادت‌های پیشنهادی

1. ALLP Manager را با کاربر عادی اجرا کنید، نه sudo allp کلی.
2. برای نصب حساس و تکرارپذیر از --from استفاده کنید.
3. Backend ناآشنا و Batch نگهداری را Dry Run کنید.
4. Lockهای Package Manager را حذف نکنید.
5. مالک Registry را بررسی کنید و فقط به نام آشنا اعتماد نکنید.

ساختار اصلی allp <command> [arguments] [options] است. برای جزئیات بیشتر -v را یک یا چند بار اضافه کنید. گزینه‌های عمومی خروجی --json، --no-color و --no-tui هستند.

جست‌وجو و انتخاب منبع

allp search ripgrep --exact
allp search editor --all --limit 50
allp search black --scope dev
allp search pycharm --from snap

خروجی عادی شامل نتیجه‌های Exact و تعداد محدودی Related است؛ --all نتیجه‌های Fuzzy را هم نشان می‌دهد. اجرای JSON یا Non-interactive بدون Scope صریح به‌صورت پیش‌فرض محدوده Apps را جست‌وجو می‌کند.

عملیات تغییردهنده

allp install org.mozilla.firefox --from flatpak --dry-run
allp install black --from pipx --no-interactive --yes
allp remove ripgrep --from cargo --dry-run

• --dry-run: اعتبارسنجی و ساخت Plan بدون اجرا.
• --no-interactive: هیچ Selector یا Prompt نمایش داده نشود.
• --yes: فقط تأیید نهایی ALLP Manager را بعد از حل همه انتخاب‌ها رد می‌کند.
• --allow-bootstrap: همراه --yes اجازه اجرای پیش‌نیاز جداگانه را در اتوماسیون می‌دهد.

نگهداری

allp update --skip-self-update
allp update --self-only
allp update --check-only
allp update --offline
allp update --scope dev --target tools --dry-run
allp upgrade --scope dev --target all --dry-run
allp upgrade --allow-stale-metadata  # فقط بازیابی صریح

Targetهای توسعه project، workspace، global، environment، tools و all هستند. ترکیب پشتیبانی‌نشده گزارش می‌شود و ALLP Manager چیزی را حدس نمی‌زند.

Inventory و اطلاعات

allp list --from apt --filter openssl --limit 20 --no-pager
allp info firefox --from flatpak
allp info git --full
allp info git --from apt --raw

--raw خروجی Native Backend و --full فیلدهای نرمال بیشتر را نشان می‌دهد.

Exit Codeهای پایدار

جزئیات دقیق در قرارداد فرمان‌ها قرار دارد.

ALLP Manager Backendهای دارای Capability را با Concurrency محدود جست‌وجو می‌کند. هر Parser علاوه بر Candidate، Issue ساختاریافته برمی‌گرداند؛ خروجی Native ناشناخته و غیرخالی unrecognized_output است، نه «بدون نتیجه» ساختگی.

انتخاب Scope پیش از اجرا، بک‌اندهای مجاز را محدود می‌کند. بک‌اند بیرون از Scope اصلاً فراخوانی نمی‌شود تا بعداً نتیجهٔ آن حذف شود؛ کار نامرتبط انجام نمی‌شود، اما سرعت واقعی به منابع فعال و سیستم بستگی دارد.

رتبه‌بندی

1. تطبیق Exact با Package ID یا Display Name.
2. نتیجه Related با سقف هر Backend و انتخاب Round-robin.
3. نتیجه Fuzzy که فقط با --all دیده می‌شود.

allp search git --exact
allp search editor --limit 10
allp search editor --all --limit 50

Identity میان Backendها فقط اطلاعات می‌دهد: Mapping تأییدشده می‌تواند Group بسازد، رابطه احتمالی با عدم قطعیت نشان داده می‌شود و هم‌نام ساده جدا می‌ماند. ALLP Manager هیچ منبع معناداری را خودکار انتخاب نمی‌کند.

کنترل‌های تعاملی

در نتیجه بلند، Space/b صفحه جلو/عقب، / Filter، عدد انتخاب Global، Enter انتخاب Highlight/اول و q یا Escape لغو است. Filter شماره اصلی را تغییر نمی‌دهد.

اجرای بدون تعامل

Script نمی‌تواند به سؤال Scope یا Source جواب دهد؛ آن‌ها را صریح بدهید:

allp search git --scope apps --json
allp install git --from apt --dry-run --no-interactive
allp install git --from apt --no-interactive --yes

اگر ابهام باقی بماند Exit Code شماره ۴ همراه راه بازیابی برمی‌گردد.

ALLP Manager در هر اجرا Backendها را دوباره کشف می‌کند و فقط Capability واقعاً موجود را اعلام می‌کند. Experimental یعنی پیاده‌سازی و با Fake PATH تست شده، ولی هنوز به اعتبارسنجی گسترده روی سیستم واقعی نیاز دارد.

Backendهای سیستمی

APT Metadata را با apt-get update تازه می‌کند. Pacman عمداً Update مستقل ندارد، چون Partial Upgrade امن نیست و از Sync+Upgrade کامل استفاده می‌کند. DNF هر دو شکل خروجی DNF4 و DNF5 را پوشش می‌دهد.

روی Bazzite تغییر Host از طریق DNF غیرفعال است و rpm-ostree Refresh، ارتقای Image و Layering صریح را انجام می‌دهد. Layering معمولاً Reboot می‌خواهد و بعد از پیشنهاد Flatpak، Homebrew یا Container به‌عنوان آخرین راه نشان داده می‌شود.

Flatpak

وضعیت‌های «ابزار نصب نیست»، «بدون Remote»، «آماده» و «Probe شکست‌خورده» جدا هستند. افزودن Flathub یک Plan مستقل و User-scoped است.

allp doctor flatpak
allp search firefox --from flatpak
allp install org.mozilla.firefox --from flatpak --dry-run

Snap

Snap ابتدا از Socket محلی snapd برای جست‌وجوی گسترده، Resolve دقیق، نصب و پیگیری Change استفاده می‌کند. نام Canonical، Publisher، Confinement، معماری، Channel و وضعیت نصب قبل از Plan بررسی می‌شوند. پاسخ قطعی snap-not-found به CLI قدیمی Fallback نمی‌کند؛ Fallback فقط برای خطای Transport/Compatibility است.

allp doctor snap
allp install pycharm --from snap --dry-run

--classic فقط وقتی Metadata واقعاً Classic بودن را اعلام کند اضافه می‌شود.

Homebrew

Detect، Doctor و عملیات از یک Locator اعتبارسنجی‌شده استفاده می‌کنند. مسیر تنظیم‌شده، State قبلی، مسیر کاربر اصلی و Prefix رسمی بررسی می‌شوند. در اجرای sudo allp نیز Homebrew با Owner تأییدشده اجرا می‌شود.

allp doctor homebrew --verbose --no-color
sudo allp update --from homebrew --dry-run --skip-self-update

Python، Node و Rust

هم‌نام بودن یک پکیج Registry به معنی رسمی‌بودن نیست و نتیجه Fuzzy خودکار نصب نمی‌شود. Scope کاربر/پروژه حفظ می‌شود و این ابزارها مخفیانه Root نمی‌شوند.

allp install black --from pipx --dry-run
allp install typescript --from pnpm --dry-run
allp install ripgrep --from cargo --dry-run

نگهداری Cargo هیچ‌وقت cargo add یا cargo update پروژه را اجرا نمی‌کند. ارتقای Binaryهای Global به ابزار اختیاری cargo-update نیاز دارد. جدول دقیق در Capability Matrix نگه‌داری می‌شود.

ALLP Manager پیش از اجرای Batch نگهداری، Plan تمام Backendهای انتخابی را می‌سازد. Refresh شدن Metadata در APT پیش‌نیاز Upgrade همان Backend است؛ شکست آن Upgrade را عقب می‌اندازد، مگر کاربر صریحاً Metadata قدیمی را بپذیرد.

allp update --dry-run
allp upgrade --dry-run
allp upgrade --allow-stale-metadata  # فقط بازیابی

معنا را Backend تعیین می‌کند: APT/DNF Metadata را تازه می‌کنند، Pacman Sync و Upgrade را ترکیب می‌کند، Flatpak/Snap اپ‌های نصب‌شده را Refresh می‌کنند، Homebrew Metadata و Package Upgrade را جدا می‌کند و rpm-ostree تغییر تراکنشی Stage می‌کند.

کنترل‌های Self-update

allp self-update --check-only
allp self-update --update-channel stable
allp self-update --update-channel continuous
allp self-update --update-channel prerelease
allp update --skip-self-update
allp update --self-only
allp update --offline

نصب تازه Stable است و انتخاب صریح Channel ذخیره می‌شود. Offline نه GitHub و نه Source پکیج را صدا می‌زند. Build محلی جدیدتر Downgrade نمی‌شود و LocalAhead گزارش می‌گردد.

Asset رسمی با OS، معماری، libc و Target از Manifest و شواهد SHA-256 انتخاب می‌شود. Backup تا تأیید Binary جدید حفظ می‌شود. جایگزینی موفق در allp update فقط یک بار برنامه جدید را اجرا و نگهداری Backendها را بدون Loop ادامه می‌دهد.

Profile یک Inventory نسخه‌دار و Experimental در قالب TOML است که هم Package ID و هم Backend مالک را حفظ می‌کند.

allp profile save workstation
allp profile list
allp profile show workstation
allp profile export workstation workstation.toml
allp profile import workstation.toml --name laptop
allp profile install laptop --dry-run
allp profile install laptop

version = 1
name = "developer-tools"

[[packages]]
backend = "apt"
package = "git"

[[packages]]
backend = "rust"
package = "ripgrep"
version = "14.1.1"

Version فقط Metadata مشاهده‌شده است و Pin نیست. ALLP Manager پکیج APT را به DNF ترجمه نمی‌کند. پیش از اجرا همه Backendها یک‌جا بررسی می‌شوند تا نبود یک Backend بعد از تغییرهای قبلی Host را نیمه‌کاره نگذارد؛ سپس مسیر عادی Search، Plan و تأیید برای هر Package اجرا می‌شود.

Inventory سیستمی ممکن است Dependencyها را هم داشته باشد؛ فایل Export را قبل از انتقال بازبینی کنید. Import فیلد ناشناخته، Entry تکراری، نام ناامن، نسخه پشتیبانی‌نشده و اندازه غیرعادی را رد می‌کند. Writeها Atomic و دارای Rollback هستند.

در Linux معمولاً فایل‌ها در ~/.config/allp/profiles/ هستند؛ مسیر واقعی را با allp doctor ببینید.

محدودیت‌های نصب در نسخهٔ ۰.۶.۴

نسخهٔ ثبت‌شدهٔ پکیج مشاهدهٔ موجودی است و نسخه را ثابت نمی‌کند؛ نصب از نسخهٔ فعلیِ در دسترس بک‌اند استفاده می‌کند. نصب پروفایل برای هر پکیج تأیید می‌گیرد و در اولین عملیات ناموفق متوقف می‌شود؛ پکیج‌های قبلاً نصب‌شده باقی می‌مانند. ادامهٔ خودکار فقط برای موارد ناموفق وجود ندارد. پیش از اجرای دوباره، عملیات انجام‌شده را بررسی کنید و در صورت نیاز یک پروفایل جدا برای تلاش مجدد بسازید.

در اجرای بدون تعامل Backend و Scope را صریح تعیین کنید. JSON برای فرمان‌های Read-only و Dry Run نگهداری پشتیبانی می‌شود و Prompt، رنگ یا Spinner انسانی با Stdout ساختاریافته مخلوط نمی‌شود.

allp detect --json
allp search git --from apt --json
allp list --from flatpak --json
allp info git --from apt --json
allp update --dry-run --json
allp upgrade --dry-run --json

Envelope

{
  "schema_version": 2,
  "command": "search",
  "complete": true,
  "results": {"query": "git", "candidates": [], "groups": [], "backends": []},
  "issues": []
}

schema_version مرز سازگاری و complete سیگنال کیفیت داده است. مقدار False ممکن است همراه Candidate معتبر باشد، چون یک Backend خروجی ناقص یا ناشناخته داده؛ قبل از اقدام issues را بررسی کنید.

report="$(mktemp)"
if allp search git --from apt --json >"$report"; then
  jq -e '.schema_version == 2 and .complete == true' "$report" >/dev/null
  jq '.results.candidates[] | {backend_id, package_id, match_kind}' "$report"
fi
rm -f "$report"

برای اتوماسیون تغییر، اول Dry Run را ذخیره کنید و بعد Backend/Package دقیق را با --no-interactive --yes اجرا کنید. --yes منبع مبهم یا Bootstrap را تأیید نمی‌کند؛ Bootstrap به --allow-bootstrap هم نیاز دارد. Exit Code شماره 8 یعنی بخشی از Batch شکست خورده و موفقیت کامل نیست.

تمام فیلدها در JSON_SCHEMA.md تعریف شده‌اند.

ALLP Manager از قرارداد Data Directory هر Platform پیروی می‌کند. در Linux مسیرها معمولاً زیر ~/.config/allp، ~/.local/state/allp و ~/.cache/allp هستند. در Script مسیر را حدس نزنید؛ allp doctor مقدار واقعی Environment را نشان می‌دهد.

Profileها در profiles/*.toml زیر Config هستند و State به‌شکل Atomic نوشته می‌شود. مسیر ذخیره‌شده Homebrew پیش از استفاده دوباره اعتبارسنجی می‌شود.

allp doctor مسیر واقعی، مالکیت/Writable بودن Executable، کاربر فعلی و اصلی و Release Target را بدون چاپ Token یا Environment نامرتبط گزارش می‌کند. متغیرهای ALLP_TEST_* و متغیرهای ادامه داخلی API عمومی تنظیمات نیستند؛ از Flagهای مستند و Profile استفاده کنید.

اجرای واقعی و Interactive فرمان‌های update و upgrade می‌تواند Footer زنده شبیه APT داشته باشد. Stdout/Stderr Native در Scrollback عادی می‌ماند و Footer درصد، Backend/Action فعال، زمان و وضعیت Queue را نشان می‌دهد. Renderer فقط Observer است و Argv یا Privilege برنامه‌ریزی‌شده را تغییر نمی‌دهد.

allp update
allp upgrade
allp update --no-tui
allp update --no-color

در JSON، Dry Run، Redirect/Non-TTY، TERM=dumb و --no-interactive نمای زنده خاموش است. Control Sequence غیرقابل‌اعتماد Native پاک‌سازی و Footer متناسب با عرض Terminal کوتاه می‌شود.

اگر Child نیازمند Root باشد، احراز sudo قبل از Renderer تمام می‌شود. انقضای Credential، Footer را تعلیق و بیرون آن دوباره اعتبارسنجی می‌کند؛ شکست به‌عنوان Operation مسدود طبقه‌بندی می‌شود.

ALLP Manager یک برنامه Rust 2021 بر پایه مدل‌های Domain، Capabilityهای Backend و Execution Planهای تغییرناپذیر است.

CLI
 └─ App bootstrap
    ├─ PlatformContext + RuntimePrivilegeContext
    ├─ CapabilityRegistry + RequirementSet
    ├─ Detector → DetectedBackendSet
    └─ Operation → Query/Plan → Renderer → ProcessRunner

Self-update
 └─ منبع GitHub ثابت → Manifest → اعتبارسنجی Stage
    → جایگزینی مخصوص Platform → بررسی/Rollback → ادامه محافظت‌شده

مسئولیت ماژول‌ها

قانون‌های تغییرناپذیر

1. Discovery در هر اجرا تازه است.
2. Operation عمومی با Capability کار می‌کند، نه Backend ID ثابت.
3. Flag و Parser بومی داخل ماژول Backend می‌ماند.
4. Backend تغییردهنده Plan برمی‌گرداند و Process اجرا نمی‌کند.
5. Runner برای عملیات پکیج از std::process::Command با فایل اجرایی و آرگومان‌های جدا استفاده می‌کند. استثنا، نصب اولیهٔ رسمی Homebrew است: یک Plan آشکار و جداگانه‌تأییدشده با /bin/bash -c نصاب رسمی را در فایل موقت دانلود و با /bin/bash اجرا می‌کند. دانلود به Shell پایپ نمی‌شود؛ در این مسیر فعلاً checksum ثابتِ نصاب بررسی نمی‌شود.
6. چند منبع معنادار به تصمیم کاربر نیاز دارند.
7. خروجی ناشناخته Parser هرگز «بدون نتیجه» فرض نمی‌شود.

جریان Search

Backendها با Concurrency محدود Query می‌شوند. نتیجه به Exact، Related و Fuzzy نرمال می‌شود. Exact همیشه دیده می‌شود، Related به‌شکل Round-robin میان Backendها انتخاب می‌شود و Fuzzy به --all نیاز دارد. رابطه تأییدشده، رابطه احتمالی و صرفاً هم‌نام جدا نمایش داده می‌شوند.

افزودن Backend

Backend باید قرارداد src/backends/contract.rs را پیاده کند، Requirement و Capability را اعلام کند، Parser/Plan خود را نگه دارد، یک بار در Catalog ثبت شود و Fixture و Test داشته باشد.

make quality
bash scripts/check-architecture.sh

قواعد مرجع در ARCHITECTURE.md و ADDING_BACKEND.md هستند.

ALLP Manager ابزارهایی را هماهنگ می‌کند که ممکن است سیستم‌عامل را تغییر دهند. ویژگی امنیتی اصلی آن Plan قابل‌مشاهده و مرز اجرای محدود است؛ نه ادعای قابل‌اعتمادبودن تمام پکیج‌های ثالث.

مرز فرمان و دسترسی

• Runner برای عملیات پکیج از std::process::Command با فایل اجرایی و آرگومان‌های جدا استفاده می‌کند. استثنا، نصب اولیهٔ رسمی Homebrew است: یک Plan آشکار و جداگانه‌تأییدشده با /bin/bash -c نصاب رسمی را در فایل موقت دانلود و با /bin/bash اجرا می‌کند. دانلود به Shell پایپ نمی‌شود؛ در این مسیر فعلاً checksum ثابتِ نصاب بررسی نمی‌شود.
• Package ID که با - شروع شود قبل از تغییر رد می‌شود.
• Executable نیازمند Root و Parentهای آن Canonical و از نظر مالکیت/Permission بررسی می‌شوند.
• اجرای عادی با کاربر شروع می‌شود و فقط Child لازم sudo -- می‌گیرد.
• Maintenance یک بار sudo -v می‌گیرد و بعد sudo -n -- اجرا می‌کند تا Prompt وارد UI نشود.
• Homebrew، Python، Node، Cargo و Flatpak کاربری به Original User تأییدشده برمی‌گردند.
• عملیات User-scoped در Root مستقیم، وقتی کاربر اصلی معلوم نیست، رد می‌شود.

مدل تأیید

allp install git --from apt --dry-run  # بدون تغییر و بدون sudo
allp install git --from apt            # Plan → تأیید → اجرا
allp install git --from apt --yes      # فقط ردکردن تأیید نهایی Allp

Bootstrap یک تغییر مستقل است. اجرای بدون تعامل آن بعد از نمایش Plan دقیق، به هر دو گزینه --yes --allow-bootstrap نیاز دارد.

اعتماد به Registry و خروجی

خروجی Package Manager داده غیرقابل‌اعتماد است. اسم‌های Registryهای Python، Node و Rust رسمی فرض نمی‌شوند و Fuzzy Match خودکار نصب نمی‌شود. Build Script یا Installer Hook ممکن است در نصب Native واقعی اجرا شود، اما در Dry Run هرگز.

زنجیره اعتماد Self-update

فقط هویت Repository رسمی Compile‌شده پذیرفته می‌شود. درخواست HTTPS محدود است؛ هویت Manifest، Target، نام آرشیو، Size و SHA-256 بررسی می‌شوند و Path/Link ناامن رد می‌شود. هویت Build و Byteهای فایل Stage در تمام Helperها دوباره بررسی می‌شوند. Backup تا Post-check موفق نگه داشته می‌شود. Binary متعلق به dpkg/rpm/Pacman بازنویسی نمی‌شود و Update به همان منبع Native سپرده می‌شود.

حریم خصوصی و گزارش

ALLP Manager Telemetry، Daemon، ذخیره رمز sudo یا Credential Store ندارد. Injection، Privilege Escalation، Resolve ناامن، افشای Credential یا JSON گمراه‌کننده را از Private Security Advisory گزارش کنید، نه Issue عمومی.

نسخه Alpha ممیزی امنیتی نشده است. SECURITY.md و مدل مرجع امنیت را بخوانید.

آماده‌سازی محیط

git clone https://github.com/allp-manager/allp-manager.git
cd allp-manager
rustup show
cargo build
cargo run -- detect

حداقل Rust نسخه 1.74 است و rust-toolchain.toml کانال Stable را با rustfmt و Clippy دنبال می‌کند.

Quality Gate

make fmt-check
make check
make clippy
make test
make architecture
make release
make docs-check
make quality

تست‌ها از Executable جعلی و Fixture استفاده می‌کنند و نباید عملیات مخرب Package Manager واقعی را اجرا کنند. تغییر Parser به Fixture نماینده نیاز دارد. تغییر رفتار هم باید Changelog بخش Unreleased، Regression Test و Guardrail تازه داشته باشد.

چک‌لیست Backend

1. Identity، Category، Requirement و Capability دقیق را اعلام کنید.
2. Argv و Parser بومی را داخل ماژول Backend نگه دارید.
3. برای Mutation فقط Plan برگردانید و Process اجرا نکنید.
4. Scope و Privilege را تعریف کنید.
5. Fixture موفق، بدون نتیجه، خروجی خراب و Failure اضافه کنید.
6. فقط یک بار در src/backends/catalog.rs ثبت کنید.
7. make quality را اجرا کنید.

CI و Release

CI شامل Quality Gate لینوکس، تست قابل‌حمل Linux/macOS/Windows، Cross-target، قرارداد Bootstrap خانواده‌ها و Canary هفتگی Backend است. Release آرشیو مخصوص Target، Checksum و Manifest می‌سازد.

make hooks-install
make release-prepare BUMP=patch
make release-status
# commit: release: Allp vX.Y.Z
make release-push

Prepare فایل‌های نسخه را تغییر می‌دهد و Quality Gate را اجرا می‌کند. Hook فقط Tag محلی Annotated و فایل Ignored در dist/ می‌سازد؛ تا make release-push چیزی Push یا Publish نمی‌شود.

پیش از مشارکت CONTRIBUTING.md، Regression Guardrails و راهنمای Release را بخوانید.

با شواهد Read-only شروع کنید:

allp --version --verbose
allp doctor
allp detect --verbose
allp detect --json >allp-detect.json

بعد از شکست Metadata در APT علت اصلی را برطرف کنید. --allow-stale-metadata فقط راه بازیابی صریح است، نه رفتار معمول.

در Bug Report فرمان دقیق، نسخه توزیع و ابزار، انتظار، خروجی Native و نسخه پاک‌شده allp detect --json را بفرستید. Credential یا جزئیات آسیب‌پذیری را عمومی نکنید.

آیا ALLP Manager یک Package Manager جدید است؟ خیر؛ ابزار Native نصب‌شده را هماهنگ می‌کند و Dependency Resolver یا دیتابیس جهانی ندارد.

دستور Native را پنهان می‌کند؟ خیر؛ Argv، Source، Scope و Privilege تغییر قبل از تأیید نمایش داده می‌شوند.

باید sudo allp اجرا کنم؟ معمولاً خیر؛ با کاربر عادی اجرا کنید تا فقط Child نیازمند Root ارتقا پیدا کند.

Update و Upgrade یکی هستند؟ خیر؛ Backend معنا را تعیین می‌کند. معمولاً اولی Metadata و دومی نرم‌افزار نصب‌شده را تغییر می‌دهد.

آیا --yes همه چیز را قبول می‌کند؟ خیر؛ فقط تأیید نهایی ALLP Manager را رد می‌کند. منبع مبهم و Bootstrap همچنان صریح هستند.

Profile نسخه دقیق را بازسازی می‌کند؟ فعلاً خیر؛ Format نسخه ۱ فقط Version مشاهده‌شده را ثبت می‌کند و Pin نیست.

Lockfile پروژه تغییر می‌کند؟ نگهداری Host در Cargo هرگز چنین کاری نمی‌کند. عملیات پروژه Python/Node به Target/Scope صریح نیاز دارد و محافظه‌کار است.

برای Production سخت‌سازی شده؟ پروژه Public Alpha و بدون ممیزی امنیتی است.

تفاوت ALLP Manager با Topgrade چیست؟

Topgrade بر شناسایی ابزارهای نصب‌شده و اجرای دستورهای به‌روزرسانی آن‌ها تمرکز دارد و دستورهای سفارشی را هم پشتیبانی می‌کند. ALLP Manager روند کشف و انتخاب پکیج را اضافه می‌کند: جست‌وجو میان منابع مجاز، بررسی پکیج، انتخاب صریح بک‌اند و بازبینی دستور اصلی نصب. انتخاب به روند موردنیاز شما بستگی دارد؛ در هر دو حالت مدیریت پکیج‌ها بر عهدهٔ ابزارهای اصلی باقی می‌ماند.