13.6. راهنمای خط فرمان
اهداف
هدف از این سند ارائه مسیری روشن برای کمک به طراحی یک تجربه خط فرمان لذتبخش است. این سند حاوی دستورالعملهایی است که باید برای اطمینان از داشتن یک تجربه کاربری سازگار و قابلدسترس دنبال شوند.
بررسی اجمالی
دستور nix یک ورودی واحد برای تعدادی زیردستور فراهم میکند که به توسعهدهندگان و مدیران سیستم در چرخه عمر یک پروژه نرمافزاری کمک میکنند. ما بهویژه باید توجه ویژهای به راهنمایی و یاری رساندن به کاربران جدید Nix داشته باشیم.
نامگذاری COMMANDS
کلمات اهمیت دارند. نامگذاری بخش مهمی از قابلیت استفاده است. کاربران بهطور مرتب با Nix تعامل خواهند داشت، بنابراین ما باید چیزها را برای درک آسان نامگذاری کنیم.
توصیه میکنیم از اصل کمترین تعجب پیروی کنید. این یعنی نباید هرگز از سرنامها یا مخففها استفاده کنید، مگر اینکه بهطور رایج در ابزارهای دیگر استفاده شده باشند (مانند nix init). و اگر نام دستور خیلی طولانی است (> ۱۰-۱۲ کاراکتر)، کوتاه کردن آن منطقی است (مثلاً “prioritization” تبدیل شود به “priority”).
دستورات باید از گفتگوی اسم-فهرست (noun-verb) پیروی کنند. اگرچه قالببندی اسم-فهرست از منظر گفتاری معکوس به نظر میرسد (یعنی nix store copy در برابر nix copy store)، اما به ما اجازه میدهد دستورات را همانگونه که کاربران دربارهی انجام یک عمل فکر میکنند (ابتدا گروه، سپس دستور) سازماندهی کنیم.
قوانین نامگذاری
قوانین اینجا هستند تا با محدود کردن گزینههایتان، شما را راهنمایی کنند. اما همهچیز همیشه در قالب قوانین نمیگنجد. در آن موارد، استثناها را در پیوست ۱: استثناهای نامگذاری دستورات مستند کنید و دلیل آن را ارائه دهید. این قوانین میخواهند توسعهدهنده Nix را وادار کنند که نه فقط به دستورِ در دست اقدام، بلکه به دستور در یک زمینه کامل در کنار سایر دستورات nix نیز نگاه کند.
$ nix [<GROUP>] <COMMAND> [<ARGUMENTS>] [<OPTIONS>]- عبارتهای
GROUP،COMMAND،ARGUMENTSوOPTIONSباید با حروف کوچک و به صورت مفرد نوشته شوند. - عبارت
GROUPباید یک اسم (NOUN) باشد. - عبارت
COMMANDباید یک فعل (VERB) باشد. - دربارهی
ARGUMENTSوOPTIONSدر بخش ورودی بحث شده است.
دستهبندی
برخی دستورات اهمیت بیشتری دارند و برخی دیگر کمتر. در حالی که ما میخواهیم تمام دستوراتمان بینقص باشند، اما زمان محدودی برای تست و بهبود آنها در اختیار داریم.
این دستهبندی تلاش میکند تا دستورات را از نظر اهمیت برای کاربران جدید (کاربرانی که احتمالاً بیشترین تأثیر را از تجربهکاربری نامناسب میپذیرند) به ۳ دسته تقسیم کند.
دستورات اصلی
دستوراتی که برای موارد استفادهی اصلی ما به کار میروند و بیشترین احتمال استفاده توسط کاربران جدید را دارند. ما انتظار توجه به جزئیات را داریم، از جمله:
- استفادهی صحیح از رنگها، اموجیها و تراز متن.
- تکمیل خودکار (Autocomplete) گزینهها.
- نمایش مراحل بعدی احتمالی.
- نمایش برخی «نکات» هنگام اجرای تسکهای در حال اجرا (مانند ساختن / بارگیری) به منظور آموزش نکات جالب از بومسازگان Nix به کاربران.
- صفحات راهنما تا حد امکان به بهترین شکل نوشته شوند و برای اطلاعات بیشتر به مستندات و آموزشهای خارجی اشاره کنند.
نمونههایی از چنین دستوراتی:
nix init،nix develop،nix build،nix run، ...دستورات کماستفاده
از دستورات کماستفاده انتظار توجه کمتری به جزئیات داریم، اما باز هم مواردی انتظار میرود:
- استفادهی صحیح از رنگها، اموجیها و تراز متن.
- تکمیل خودکار (Autocomplete) گزینهها.
نمونههایی از چنین دستوراتی:
nix edit،nix eval، ...دستورات ابزاری و اسکریپتنویسی
دستوراتی که برخی قابلیتهای داخلی
nixرا نمایش میدهند و بیشتر توسط اسکریپتهای دیگر استفاده میشوند.- تکمیل خودکار (Autocomplete) گزینهها.
نمونههایی از چنین دستوراتی:
nix store copy،nix hash base16،nix store ping، ...
راهنما ضروری است
راهنما باید در خط فرمان شما تعبیه شده باشد تا کاربران جدید بتوانند در صورت نیاز، به تدریج ویژگیهای جدید را کشف کنند.
به دنبال راهنما
از آنجا که هیچ روش استانداردی برای نحوهی جستجوی کاربر به دنبال راهنما وجود ندارد، ما به روشهایی تکیه میکنیم که توسط ابزارهای رایج برای ارائهی راهنما استفاده میشوند. به عنوان راهنمایی برای این موضوع، ما git را در نظر گرفتیم و هر زمان که شک داشتیم، آن را به عنوان جهتگیری ترجیحی نگاه کردیم.
قوانین عبارتند از:
- راهنما با استفاده از دستور
--helpیاhelpنمایش داده میشود (مثلاًnix--``helpیاnix help). - برای غیردستورها (مانند
nix--``helpوnix store--``help)، ما خلاصهای از رایجترین موارد استفاده را نمایش میدهیم. خلاصه روی STDOUT بدون هیچگونه استفاده از PAGER ارائه میشود. - برای دستورها (مانند
nix init--``helpیاnix help init)، ما منپِیج (man page) آن دستور را نمایش میدهیم. به طور پیشفرض از PAGER استفاده میشود (مانندgit). - در انتهای خلاصه یا منپِیج باید یک URL وجود داشته باشد که به نسخهی آنلاین مستندات دقیقتر اشاره کند.
- ساختار خلاصهها و منپِیجها باید مشابه
gitباشد.
پیشبینی اینکه کجا به راهنما نیاز است
حتی بهتر از اینکه از کاربر بخواهیم به دنبال راهنما بگردد، این است که پیشبینی کنیم چه زمانی کاربر ممکن است به آن نیاز داشته باشد؛ چه به دلیل کمبود قابلیت کشف (discoverability)، خطای تایپی در ورودی، یا صرفاً استفاده از فرصت برای آموزش جزئیات جالب - اما کمتر مشهود - به کاربر.
تکمیل خودکار شل (Shell completion)
این نوع راهنما رایجترین است و تقریباً توسط کاربران انتظار میرود. ما باید بهترین تکمیل خودکار شل را برای bash، zsh و fish فراهم کنیم.
تکمیل خودکار باید زمینهآگاه باشد، به این معنی که وقتی کاربر تایپ میکند:
$ nix build n<TAB>ما باید فهرستی از فلیکها را که با n شروع میشوند نمایش دهیم.
ورودی اشتباه
همانطور که همه میدانیم، ما انسانها مدام مرتکب اشتباه میشویم. وقتی خطای تایپی رخ میدهد - چه عمدی و چه سهوی - باید نزدیکترین گزینههای ممکن را پیشنهاد کنیم یا به مستنداتی اشاره کنیم که کاربر را راهنمایی کنند تا مرتکب خطاهای مشابه نشود. در اینجا چند نمونه آورده شده است:
در مثال اول، به خاطر تایپ نام دستور اشتباه، به کاربر اخطار میدهیم:
$ nix int
------------------------------------------------------------------------
Error! Command `int` not found.
------------------------------------------------------------------------
Did you mean:
|> nix init
|> nix inputگاهی کاربران ممکن است به دلیل خطای تایپی یا صرفاً به دلیل عدم قابلیت کشفپذیری (discoverability) مرتکب اشتباه شوند. نحوه برخورد ما با این موارد باید نسبتبهبافت (context-sensitive) باشد.
$ nix init --template=template#python
------------------------------------------------------------------------
Error! Template `template#python` not found.
------------------------------------------------------------------------
Initializing Nix project at `/path/to/here`.
Select a template for you new project:
|> template#python
template#python-pip
template#python-poetryگامهای بعدی
نشان دادن اینکه گامهای بعدی احتمالی چه مواردی هستند و روند توسعهی معمول با نیکس چگونه است، میتواند برای تازهواردان بسیار ارزشمند باشد. برای مثال:
$ nix init --template=template#python
Initializing project `template#python`
in `/home/USER/dev/new-project`
Next steps
|> nix develop -- to enter development environment
|> nix build -- to build your projectآموزش کاربر
ما باید از هر فرصتی برای آموزش کاربران استفاده کنیم، اما در عین حال باید بسیار مراقب باشیم که کاربران را آزار ندهیم. مرز باریکی میان مفید بودن و آزاردهنده بودن وجود دارد.
یک نمونه از آموزش کاربران میتواند ارائهٔ نکات در مکانهایی باشد که آنها در حال انتظار هستند.
$ nix build
Started building my-project 1.2.3
Downloaded python3.8-poetry 1.2.3 in 5.3 seconds
Downloaded python3.8-requests 1.2.3 in 5.3 seconds
------------------------------------------------------------------------
Press `v` to increase logs verbosity
|> `?` to see other options
------------------------------------------------------------------------
Learn something new with every build...
|> See last logs of a build with `nix log --last` command.
------------------------------------------------------------------------
Evaluated my-project 1.2.3 in 14.43 seconds
Downloading [12 / 200]
|> firefox 1.2.3 [#########> ] 10Mb/s | 2min left
Building [2 / 20]
|> glibc 1.2.3 -> buildPhase: <last log line>
------------------------------------------------------------------------اکنون بخش Learn از خروجی جایی است که در آن به کاربران آموزش میدهید. شما باید تنها زمانی آن را نمایش دهید که میدانید یک ساخت مدتی طول خواهد کشید و کاربران ساختهایی را که فقط چند ثانیه طول میکشند، آزار ندهید.
هر ویژگی اینچنینی باید تحت بررسی و آزمایش فشردهای قرار گیرد تا تا حد امکان بازخورد جمعآوری شده و تکتک جزئیات به دقت تنظیم شوند. اگر این کار به درستی انجام شود، میتواند به ویژگی فوقالعادهای تبدیل شود که کاربران مبتدی و پیشرفته عاشق آن خواهند شد، اما اگر به طور بینقص پیادهسازی نشود، کاربران را آزار داده و تاثیر بدی بر جای خواهد گذاشت.
ورودی
ورودی یک دستور از طریق ARGUMENTS و OPTIONS فراهم میشود.
ARGUMENTS نشاندهندهی یک ورودی ضروری برای یک تابع است. هنگام انتخاب استفاده از ARGUMENTS به جای OPTIONS لطفاً از معایب همراه آن آگاه باشید:
- کاربر باید ترتیب
ARGUMENTSرا به خاطر بسپارد. اگر تنها یکARGUMENTوجود داشته باشد، این موضوع مشکلی ایجاد نمیکند. - با استفاده از
OPTIONSامکان ارائه تکمیل خودکار بسیار بهتری وجود دارد. - با استفاده از
OPTIONSامکان ارائه پیام خطای بسیار بهتری وجود دارد. - استفاده از
OPTIONSبه این معناست که تایپ کردن کمی بیشتر خواهد بود.
ما استفاده از ARGUMENTS را منع نمیکنیم، بلکه صرفاً میخواهیم هر توسعهدهنده معایب آن را در نظر بگیرد و عاقلانه انتخاب کند.
نامگذاری OPTIONS
تنها قرارداد نامگذاری — به جز مواردی که در بخش نامگذاری COMMANDS ذکر شد — نحوه نامگذاری پرچمها (flags) است.
پرچمها نوعی از OPTION هستند که گزینهای قابل روشن (ON) یا خاموش (OFF) کردن را نمایش میدهند. میتوانیم بگوییم پرچمها از نوع بولین (boolean) برای **OPTION** هستند.
در اینجا چند نمونه از OPTIONS پرچمی آورده شده است:
--colorsدر مقابل--no-colors(نمایش رنگها در خروجی)--emojisدر مقابل--no-emojis(نمایش ایموجیها در خروجی)
درخواست (Prompt) در صورت عدم ارائه ورودی
برای دستورهای اصلی (مطابق با دستهبندی)، ما میخواهیم دستور، قابلیت کشفپذیری (discoverability) ورودیهای احتمالی را بهبود بخشد. یک کاربر جدید احتمالاً نخواهد دانست که کدام ARGUMENTS و OPTIONS مورد نیاز هستند یا چه مقادیری برای آن گزینهها امکانپذیر است.
در صورتی که کاربر ورودی را ارائه نکند یا ورودی اشتباهی بدهد، به جای نمایش خطا، با یک گزینه برای یافتن و انتخاب ورودی صحیح به کاربر پیام دهید (به مثالها مراجعه کنید).
البته زمانی که TTY به STDIN متصل نباشد، نمایش درخواست نیازی نیست. این بدان معناست که اسکریپتها نیازی به مدیریت درخواست نخواهند داشت، بلکه خطاها را مدیریت خواهند کرد.
مکانی برای استفاده از پرسش و ارائه انتخاب تعاملی به کاربر
$ nix init
Initializing Nix project at `/path/to/here`.
Select a template for you new project:
|> py
template#python-pip
template#python-poetry
[ Showing 2 templates from 1345 templates ]جای عالی دیگر برای افزودن اعلانها، دروازههای تأیید برای اقدامات خطرناک است. برای مثال، هنگام افزودن یک substitutor جدید از طریق OPTIONS یا از طریق flake.nix، باید برای اولین بار به کاربر اعلان نشان دهیم و به او اجازه دهیم آنچه را که قرار است رخ دهد بررسی کند.
$ nix build --option substitutors https://cache.example.org
------------------------------------------------------------------------
Warning! A security related question needs to be answered.
------------------------------------------------------------------------
The following substitutors will be used to in `my-project`:
- https://cache.example.org
Do you allow `my-project` to use above mentioned substitutors?
[y/N] |> yخروجی
خروجی ترمینال از بسیاری جهات میتواند بسیار محدودکننده باشد؛ امری که باید ما را وادار کند تا حتی بیشتر دربارهی تجربهٔ کاربری بیندیشیم. درست مانند هر طراحی دیگری، خروجی سازشی است میان مختصر بودن و مفصل بودن، میان نمایش راهنما به کاربران تازهکار و آزار دادن کاربران حرفهای. به همین دلیل، دانستن اینکه اولویتها چیستند اهمیت زیادی دارد.
خط فرمان Nix باید پیش از هر چیز با در نظر گرفتن کاربران تازهکار نوشته شود. اما کاربران برای مدت طولانی تازهکار باقی نمیمانند و آنچه روزی مفید بود، ممکن است به سرعت آزاردهنده شود. هیچ قانون طلایی در این راهنما وجود ندارد که بتوانیم ارائه دهیم تا کشیدن مرز و یافتن بهترین سازش را آسانتر کند.
آنچه ما تشویق به انجام آن میکنیم، ساخت نمونههای اولیه (prototypes)، انجام مقداری تست کاربری (user testing) و جمعآوری بازخورد (feedback) است. سپس تکرار چندبارهی این چرخه.
ابتدا مسیر هموار (happy path) را طراحی کنید و تنها پس از رفع اشکالات آن، به کار بر روی حالتهای مرزی (edge cases) (مدیریت و نمایش خطاها، تغییرات خروجی توسط برخی OPTIONS و غیره…) ادامه دهید.
از بهترین روشها پیروی کنید
نیازی به گفتن نیست که Nix ما باید شهروند خوبی باشد و در خط فرمان از بهترین روشها پیروی کند.
به طور خلاصه: STDOUT برای خروجی است، STDERR برای پیامرسانی (به انسان) است.
STDOUT و STDERR راهی برای شما فراهم میکنند تا پیامها را به کاربر خروجی دهید و در عین حال به آنها اجازه میدهید محتوا را به یک فایل هدایت (redirect) کنند. برای مثال:
$ nix build > build.txt
------------------------------------------------------------------------
Error! Attribute `bin` missing at (1:94) from string.
------------------------------------------------------------------------
1| with import <nixpkgs> { }; (pkgs.runCommandCC or pkgs.runCommand) "shell" { buildInputs = [ (surge.bin) ]; } ""از آنجا که این هشدار روی STDERR قرار دارد، در فایل ذخیره نمیشود.
با این حال، هر چیزی که روی STDERR قرار دارد لزوماً یک خطا نیست. برای مثال، میتوانید nix build را اجرا کنید و در حالی که همچنان پیشرفت کار را میبینید، لاگها را در یک فایل جمعآوری کنید.
$ nix build > build.txt
Evaluated 1234 files in 1.2 seconds
Downloaded python3.8-poetry 1.2.3 in 5.3 seconds
Downloaded python3.8-requests 1.2.3 in 5.3 seconds
------------------------------------------------------------------------
Press `v` to increase logs verbosity
|> `?` to see other options
------------------------------------------------------------------------
Learn something new with every build...
|> See last logs of a build with `nix log --last` command.
------------------------------------------------------------------------
Evaluated my-project 1.2.3 in 14.43 seconds
Downloading [12 / 200]
|> firefox 1.2.3 [#########> ] 10Mb/s | 2min left
Building [2 / 20]
|> glibc 1.2.3 -> buildPhase: <last log line>
------------------------------------------------------------------------خطاها (در حال توسعه - WIP)
کار باقیمانده (TODO): پس از اینکه پیادهسازی مسیر اصلی (happy path) را آماده کردیم، دربارهی نحوه نمایش خطاها فکر خواهیم کرد.
فقط برای انسانها نیست
خروجیهای مختصر و قابلخواندن توسط ماشین نیز میتوانند مفید باشند، اما نباید مانع از ساخت خروجیهای زیبای خط فرمان (CLI) شوند. در صورت نیاز، دستورات باید یک پرچم --json ارائه دهند تا کاربران بتوانند بهراحتی خروجی خط فرمان (CLI) را تجزیه (parse) کرده و با آن اسکریپتنویسی کنند.
هنگامی که TTY روی STDOUT تشخیص داده نمیشود، باید تمام عناصر طراحی (بدون رنگ، بدون ایموجی و استفاده از نویسههای ASCII به جای نمادهای Unicode) را حذف کنیم. همین رفتار باید زمانی که TTY روی STDERR نیز تشخیص داده نمیشود، رخ دهد. ما نباید بخش پیشرفت / وضعیت را نمایش دهیم، بلکه فقط باید هشدارها و خطاها را چاپ کنیم.
گفتوگو با کاربر
ابزارهای خط فرمان (CLI) همیشه به شکلی واضح نشان نمیدهند چه زمانی یک عملیات انجام شده است. برای هر اقدامی که کاربر انجام میدهد، ابزار خط فرمان (CLI) شما باید واکنشی متناسب و همارز ارائه دهد و بهوضوح مشخص کند که چه اتفاقی رخ داده است. برای نمونه:
$ nix build
Downloaded python3.8-poetry 1.2.3 in 5.3 seconds
Downloaded python3.8-requests 1.2.3 in 5.3 seconds
...
Success! You have successfully built my-project.
$دستور بالا به وضوح نشان میدهد که دستور با موفقیت کامل شد. و در مورد nix build، که دستوری است که ممکن است تکمیل آن کمی طول بکشد، به همان اندازه مهم است که آغاز به کار یک دستور نیز نشان داده شود.
تراز متن
تراز متن اولین عنصر طراحی است که تمامی دستورهای Nix را به عنوان یک خانواده و نه به عنوان ابزارهای مجزای به هم چسباندهشده نشان خواهد داد.
قالبی که باید دنبال کنیم به این صورت است:
$ nix COMMAND
VERB_1 NOUN and other words
VERB__1 NOUN and other words
|> Some detailsچند قانون که میتوانیم از مثال بالا استخراج کنیم:
- هر خط باید حداقل با یک فاصله (space) شروع شود.
- کلمه اول باید یک فعل باشد و باید در سمت راست تراز شود.
- کلمه دوم باید یک اسم باشد و باید در سمت چپ تراز شود.
- اگر نتوانستید جفت فعل/اسم مناسبی پیدا کنید، نگران نباشید؛ آن را تا حد امکان برای کاربر قابل درک بسازید.
- جزئیات بیشتر هر خط را میتوان توسط کاراکتر
|>ارائه کرد که هنگام تراز کردن متن به عنوان کلمه اول عمل میکند.
فراموش نکنید که باید خروجی ترمینال خود را با غیرفعال بودن رنگها و ایموجیها (--no-colors --no-emojis) نیز تست کنید.
کمرنگ / روشن
پس از مقایسه چند ترمینال با طرحبندیهای رنگی مختلف، توصیه میکنیم از استفاده از متن کمرنگ خودداری کنید. تفاوت آن با بقیه متن در بسیاری از ترکیبهای ترمینال و طرح رنگ بسیار اندک است. گاهی اوقات این تفاوت اصلاً قابل توجه نیست، بنابراین تکیه بر آن منطقی به نظر نمیرسد.
متن روشن پشتیبانی بسیار بهتری در سراسر ترمینالها و طرحهای رنگی دارد. بیشتر اوقات این تفاوت به گونهای ادراک میشود که گویی متن روشن به صورت بولد (پررنگ) است.
رنگها
انسانها از قبل توسط جامعه شرطی شدهاند تا معنای خاصی را به رنگهای خاصی نسبت دهند. در حالی که این معنا جهانی نیست، مجموعهای ساده از رنگها برای نشان دادن احساسات پایه استفاده میشود.
رنگهایی که میتوانند در خروجی استفاده شوند:
- قرمز = خطا، خطر، توقف
- سبز = موفقیت، خوب
- زرد/نارنجی = ادامه با احتیاط، هشدار، در حال انجام
- آبی/سرخابی = پایداری، آرامش
در حالی که رنگها زیبا هستند، زمانی که خط فرمان توسط ماشینها (در اسکریپتهای اتوماسیون) استفاده میشود، میخواهید رنگها را حذف کنید. باید یک گزینه سراسری --no-colors وجود داشته باشد که رنگها را حذف کند.
کاراکترهای خاص (یونیکد)
بیشتر ترمینالها پشتیبانی خوبی از کاراکترهای یونیکد دارند و شما باید به طور پیشفرض از آنها در خروجی خود استفاده کنید. اما همیشه یک راه حل پشتیبان داشته باشید که فقط با کاراکترهای ASCII پیادهسازی شده است و زمانی که گزینه --ascii ارسال شود، استفاده خواهد شد. لطفاً مطمئن شوید که خروجی خود را بدون کاراکترهای یونیکد نیز تست میکنید.
فراتر از نمایش تمام کاراکترهای مختلف یونیکد، مهم است که مجموعه مشترکی از کاراکترها را تثبیت کنیم که از آنها برای موقعیتهای خاص استفاده میکنیم.
ایموجیها
ایموجیها به انتقال احساسات حتی بهتر از متن، رنگها و کاراکترهای خاص کمک میکنند.
ما نگه داشتن مجموعه ایموجیها در حد حداقل را توصیه میکنیم. این کار باعث میشود هر ایموجی بیشتر به چشم بیاید.
از آنجایی که همه از ایموجیها خوششان نمیآید، باید گزینهای مانند --no-emojis برای غیرفعال کردن آنها ارائه دهیم. لطفاً مطمئن شوید که خروجی خود را بدون ایموجیها نیز تست میکنید.
جدولها
تمام دستوراتی که دادههای خاصی را فهرست میکنند، میتوانند در قالب نوعی جدول پیادهسازی شوند. مهم است که هر سطر از خروجی شما یک «ورودی» واحد از دادهها باشد. هرگز مرزهای جدول (کادر جدول) را چاپ نکنید. این کار شلوغ و آزاردهنده است و تجزیه (parsing) آن با ابزارهای دیگر مانند grep را به شدت دشوار میکند.
به عرض صفحه نمایش توجه داشته باشید. به طور پیشفرض فقط چند ستون را به همراه سرتیتر جدول نمایش دهید؛ برای موارد بیشتر، میتوان جدول را با گزینههای زیر دستکاری کرد:
--no-headers: سرتیترهای ستون را به طور پیشفرض نمایش میدهد اما امکان مخفی کردن آنها را فراهم میکند.--columns: فهرست جداشده با کاما از نام ستونهایی که باید اضافه شوند.--sort: اجازه مرتبسازی بر اساس ستون را میدهد. همچنین امکان مرتبسازی معکوس و چندستونی را نیز فراهم میکند.
خروجی تعاملی
خروجی تعاملی به این منظور انتخاب شد که بتواند تعادلی میان کاربران مبتدی و پیشرفته برقرار کند. در حالی که خروجی پیشفرض کاربران مبتدی را هدف قرار میدهد، میتوان آن را تنها با چند کلید به یک ابزار دروننگری پیشرفته تبدیل کرد.
پیشرفت
برای دستورات طولانیتر، باید نمای کلی پیشرفت را ارائه دهیم.
این موضوع به بهترین شکل در مثال nix build نشان داده شده است:
$ nix build
Started building my-project 1.2.3
Downloaded python3.8-poetry 1.2.3 in 5.3 seconds
Downloaded python3.8-requests 1.2.3 in 5.3 seconds
------------------------------------------------------------------------
Press `v` to increase logs verbosity
|> `?` to see other options
------------------------------------------------------------------------
Learn something new with every build...
|> See last logs of a build with `nix log --last` command.
------------------------------------------------------------------------
Evaluated my-project 1.2.3 in 14.43 seconds
Downloading [12 / 200]
|> firefox 1.2.3 [#########> ] 10Mb/s | 2min left
Building [2 / 20]
|> glibc 1.2.3 -> buildPhase: <last log line>
------------------------------------------------------------------------جستجو
هنگامی که چندین گزینه برای انتخاب وجود دارد، از یک جستجوی فازی مشابه fzf استفاده کنید.
$ nix init
Initializing Nix project at `/path/to/here`.
Select a template for you new project:
|> py
template#python-pip
template#python-poetry
[ Showing 2 templates from 1345 templates ]اعلان (Prompt)
در برخی شرایط لازم است به کاربر اعلان کنیم و او را در جریان اتفاقاتی که قرار است رخ دهد، قرار دهیم.
$ nix build --option substitutors https://cache.example.org
------------------------------------------------------------------------
Warning! A security related question needs to be answered.
------------------------------------------------------------------------
The following substitutors will be used to in `my-project`:
- https://cache.example.org
Do you allow `my-project` to use above mentioned substitutors?
[y/N] |> yمیزان جزئیات (Verbosity)
راههای زیادی برای کنترل میزان جزئیات خروجی وجود دارد.
سطوح جزئیات عبارتند از:
ERROR(سطح 0)WARN(سطح 1)NOTICE(سطح 2)INFO(سطح 3)TALKATIVE(سطح 4)CHATTY(سطح 5)DEBUG(سطح 6)VOMIT(سطح 7)
سطح پیشفرضی که دستور با آن شروع میشود ERROR است. سادهترین راه برای افزایش جزئیات، انباشتن گزینه -v است (مثال: -vvv == سطح 3 == INFO). همچنین دو میانبر وجود دارد: --debug برای اجرا در سطح جزئیات DEBUG و --quiet برای اجرا در سطح جزئیات ERROR.
پیوست ۱: استثناهای نامگذاری دستورها
دستورهای nix init و nix repl بهخوبی جا افتادهاند