Начало

Сомнения

Орешники

Провал

Выводы

Эх, солана-солана, что же ты творишь...

ДЛЯ ВАС СТАРАЛСЯ - https://t.me/dolbaebskicode

Что же такое эфириум минты? - Этим вопросом не задаются грамотные люди, ибо знают, что минтеры - пидорасы.

Набрав в поисковике лучшей социальной сети ВКОНТАКТИ - "что такое эфириум", получил довольно вразумляющий ответ:

Ethereum - это управляемая сообществом технология, на основе которой работает криптовалюта эфир (ETH) и тысячи децентрализованных приложений.

Изучите Ethereum

Посмотреть другие варианты на DeepL.com

Как же он работает эта тварь?

Блоки и транзакции

В блоках хранятся транзакции, в транзакциях информация о всех действиях участников блокчейна.

Транзакции подробно

Для следующих тем нужно знать несколько понятий:

1. Ethereum - нативная монета, которую мы отдаём уёбкам(ныне называются валидаторами) чтобы они наши транзы подтвердили.
2. Gas limit и gas price - дань для ахуевших хуесосов(в простонародии - комиссия), которую мы должны заплатить, чтобы нашу транзу включили в сеть. Gas limit зависит от сложности транзакции(перевод стоит меньше, чем вызов функций контрактов, потому что количество переносимых байтов в транзе меньше, чем вес твоей мамаши), gas price зависит от количество поступаемых пенисов в жопу сети(Чекать тут).
3. Data - данные, которые передаются в контракт.

бля, а что нахуй такое эти ваши контракты?

Смарт-контрактики

Вот, к примеру, метод перевода в контракте юэсдитишки, который мы каждый раз используем когда хотим перевести свои стейблы

У нас есть 3 аргумента:от кого, кому и сколько - аргументы.

Конечный результат вызова функции, так называемая INPUT DATA, штука, которая хранит в себе: нейм вызываемой функции и аргументы:

Если не заглядывать под капот - компьютеру куда проще читать такую хуйню, нежели читаемый текст. в будущем объясню, как эта хуйня воркает, а пока что держи в голове, что любой вызов функции выглядит так.

Вывод

Авторы:

Левиафан / Параноик

В этом руководстве показано, как законнектиться к WebSocket ноде Эфира, генерировать кошельки, подписывать сообщения, чтение мемпула.

Про то как скачать и установить раст было в прошлой части, так что останавливаться и ждать балласт не будем.

Теперь мы создадим проект Rust и добавим необходимые зависимости.

Создайте папку нашего проекта и инициализируйте его с помощью cargo:

mkdir rust-ethereum-tutorial-part2
cd rust-ethereum-tutorial-part2
cargo init

Для удобства добавления зависимостей Rust в наш проект мы будем использовать cargo-edit:

cargo install cargo-edit

Добавим необходимые модули:

cargo add tokio eyre ethers +legacy

В отличие от прошлого туториала, конструкция подключения будет немного иная:

use ethers::prelude::*;

#[tokio::main]
async fn main() -> eyre::Result<()> {
    // Подключаемся ноде, создаем новый экземпляр провайдера.
    let client = Provider::new(
        Ws::connect("wss://eth-mainnet.g.alchemy.com/v2/rhHsBRIaD9TsoHdKpnymrJimBxPwv5Xp").await?,
    );
    
    Ok(()) // Пустое возвращаемое значение
}

Теперь когда клиент создан, можно заняться хуйней, то есть сгенерировать новый кошелек:

    let wallet = LocalWallet::new(&mut rand::thread_rng()); // Генерация рандомного кошелька
    let address = wallet.address(); // Получение адреса кошелька

    println!("ебать привет {:?}", address);

Так как мы не долбаебы, то лучше всего изучить какие-то доп. возможности объекта кошелька.

Одна из возможностей подпись сообщения:

    let signature = wallet.sign_message("Я пидор").await?; // Создание сигнатуры

    println!("{}", signature);

Сигнатура подписанного сообщения есть, но как теперь ее верефать?

Для такого есть метод verify, который на вход получает возможное сообщение и адрес кошелька.

Попробуем наебать систему и вписать какую-то хуйню:

    match signature.verify("Я не пидор", address) {
        Err(_) => println!("ХХИХХИХИ, ТЫ ЧО ПИДОР?))"),
        Ok(_) => println!("ЧОО ТЫ НЕ ПИДОР?"),
    };

Запустив наше детище в ебло прилетит сообщение ХХИХХИХИ, ТЫ ЧО ПИДОР?))

Так, а теперь попробуем ввести правильное значение, которое соответствует подписанному сообщению:

    match signature.verify("Я пидор", address) {
        Ok(_) => println!("ЧЧООО ПИДОР??"),
        Err(_) => println!("НЕЕЕЕЕЕЕ ПИДОР???"),
    };

Что же получится при запуске? - Выведется ЧЧООО ПИДОР??

Чтобы полностью овладеть БЛОКЧЕЙНОМ ЭФИРОМ и стать настоящим Терном, нужно научиться читать мемпул.

ТАААК, чтение мемпула дело простое, но требует некоторых действий.

Для начала нужно создать фильтр мемпула, то есть какого типа транзакций будут поступать при чтении.

В своем примере я решил хуй забить на фильтрацию и сделать его пустым, то есть любого вида транзакции будут поступать:

    let filter = Filter::new();

Теперь, чтобы начать читать мемпул, нам нужно передать этот своеобразный фильтр в метод subscribe_logs, который создает новый ручей подписок

    let mut stream = client.subscribe_logs(&filter).await?;

Ручей получили, а как в нем купаться? Для этого нам потребуется особенная конструкция:

    while let Some(log) = stream.next().await {}

Такая хуета позволяет постоянно получать данные из мемпула.

Чтобы понять, что находится внутри лога, достаточно ебануть под двум клавишам ctrl+space.

По аналогии я сделал что-то примерно такое:

    while let Some(log) = stream.next().await {
        println!(
            "транзакция {:?}, блок {:?}",
            log.transaction_hash, log.block_number
        );
    }

Код готов, пришло время запускать:

[meqy@meqy-hplaptop15seq2xxx eth_rust]$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.38s
     Running `target/debug/eth_rust`
ебать привет 0xda85e6532cce4869c18025aac2b34386d5c5f8ce
18350d269ad85efee75ee83ed22c84c891dd6209c27868582c9e81a65cc6ad9965002af2fd1c0174ad44bfcacd314ff6af153f1cba02e6e368f25e2d9fc6172c1b
ХХИХХИХИ, ТЫ ЧО ПИДОР?))
ЧЧООО ПИДОР??
^C

Дальше мне думать чото лень, так что ждите следующей статьи.

В этом руководстве показано, как запустить локальную виртуальную машину Ethereum (EVM) в Rust, запросить баланс и совершить простые транзакции.

Прежде чем писать код, мы должны убедиться, что у нас установлены некоторые необходимые инструменты, а именно Rust и Ganache.

Установите Rust, следуя инструкциям. Или, если вы используете Arch Linux, вы можете следовать инструкциям здесь, чтобы установить Rust.

Ganache поможет вам быстро создать среду Ethereum для тестирования. Если вам не нужен весь пакет, вы можете просто установить ganache-cli с помощью npm,

npm install -g ganache

Запустите ganache-cli, чтобы проверить, правильно ли вы его установили.

Теперь мы создадим проект Rust и добавим необходимые зависимости.

Создайте папку нашего проекта и инициализируйте его с помощью cargo:

mkdir rust-ethereum-tutorial
cd rust-ethereum-tutorial
cargo init

Для удобства добавления зависимостей Rust в наш проект мы будем использовать cargo-edit:

cargo install cargo-edit

Это добавит последнюю версию ethers в качестве зависимости в Cargo.toml:

cargo add --no-default-features ethers +legacy

и еще несколько библиотек:

cargo add tokio +full clap hex eyre

Краткое описание этих библиотек:

• tokio - позволяет нам использовать асинхронные функции в Rust
• clap - для работы с аргументами командной строки
• hex - для работы с шестнадцатеричными строками
• eyre - это библиотека, которая помогает сократить количество кодового кода при обработке ошибок

Узел Ethereum обычно предоставляет конечную точку HTTP, WebSocket или IPC для доступа к сети Ethereum. Для разработки в локальной среде мы можем подключиться к нашей конечной точке, предоставляемой локально запущенным ganache. Чтобы запустить ganache в Rust, мы можем просто использовать Ganache::new().spawn():

use ethers::utils::Ganache;
use eyre::Result;#[tokio::main]
async fn main() -> Result<()> {
    // Спавн Ganache экземпляра
    let ganache = Ganache::new().spawn();
    println!("HTTP Endpoint: {}", ganache.endpoint());
    Ok(())
}

Если мы выполним команду cargo run, мы увидим URL конечной точки, выведенный в консоли:

...
HTTP Endpoint: http://localhost:46795

При каждом запуске Ganache будет использовать случайно генерируемые мнемоники.

Чтобы сделать наш пример более детерминированным, мы можем настроить его на использование определенную мнемонику:

let mnemonic = "gas monster ski craft below illegal discover limit dog bundle bus artefact";
let ganache = Ganache::new().mnemonic(mnemonic).spawn();

Чтобы получить доступ к кошельку, созданному ganache, мы сначала получим закрытые ключи, а затем преобразуем их в экземпляр LocalWallet:

// Получите первый кошелек, управляемый ganache
let wallet: LocalWallet = ganache.keys()[0].clone().into();
let wallet_address: String = wallet.address().encode_hex();
println!("Default wallet address: {}", wallet_address);

Для взаимодействия с узлом или сетью Ethereum нам потребуется создать клиент, который подключается к конечной точке ganache:

// Провайдер - это клиент Ethereum JsonRPC.
let provider = Provider::try_from(ganache.endpoint())?.interval(Duration::from_millis(10));

Теперь, когда наш клиент подключен к сети Ethereum, мы можем запросить баланс любого адреса в нашем кошельке:

// Запросить баланс нашего счета
let first_balance = provider.get_balance(first_address, None).await?;
println!("Баланс первого адреса кошелька: {}", first_balance);

Если мы снова запустим программу cargo run, то узнаем, что по этому адресу у нас есть 1000ETH. Это добавляется программой Ganache автоматически.

Чтобы запросить баланс, используя адрес в формате шестнадцатеричной строки, нам нужно сначала преобразовать строку в тип Address:

// Запросить баланс случайного счета
let other_address_hex = "0xaf206dCE72A0ef76643dfeDa34DB764E2126E646";
let other_address = "0xaf206dCE72A0ef76643dfeDa34DB764E2126E646".parse::<Address>()?;
let other_balance = provider.get_balance(other_address, None).await?;
println!(
    "Баланс адреса {}: {}",
    other_address_hex, other_balance
);

Попробуйте cargo run, и вы увидите, что баланс этого адреса равен нулю:

Баланс адреса 0xaf206dCE72A0ef76643dfeDa34DB764E2126E646: 0

Далее мы создадим простую транзакцию для перевода нескольких токенов Ethereum на другой адрес.

// Создайте транзакцию для перевода 1000 wei на `other_address`.
let tx = TransactionRequest::pay(other_address, U256::from(1000u64)).from(first_address);
// Отправляем транзакцию и ждем получения
let receipt = provider
    .send_transaction(tx, None)
    .await?
    .log_msg("Ожидание трансфера")
    .await?
    .context("Нет получателя")?;
    
println!(
    "Транзакция замайнена на блоке {}",
    receipt.block_number.context("Не получилось получить блок транзакции")?
);
println!(
    "Баланс у {} {}",
    other_address_hex,
    provider.get_balance(other_address, None).await?
);

Выполните cargo run, вы получите следующие результаты:

Ожидание трансфера: 
0xff6153310304732bb28856ca3a90ab9c94c5c9e20cf51e8a2803f3483670cd6f
Транзакция замайнена на блоке 1
Баланс у 0xaf206dCE72A0ef76643dfeDa34DB764E2126E646 1000

Сейчас вам поведаю о создании своего API сервиса на основе Warp и Tokio.
Это является перевод данной статьи.

Прежде чем приступить к написанию кода, нужно немного продумать структуру API. Это поможет определить нужные эндпоинты, контроллеры и способы хранения данных.

Роуты

Для своего апи я определил два роута

/customers
     - GET -> получить список пользователей
     - POST -> создать нового пользователя и добавить инфомацию в хранилище
/customers/{guid}
     - GET -> получить информацию о пользователе
     - POST -> обновить информацию о пользователе
     - DELETE -> удалить пользователя из хранилища

Обработчики

На основе маршрутов мне потребовалось определить несколько обработчиков

list_customers -> вернуть список пользователей
create_customer -> создать нового пользователя и добавить его в базу данных
get_customer -> вернуть информацию о конкретном пользователе
update_customer -> обновить информацию о пользователе 
delete_customer -> удалить пользователя из базы данных

База данныхчто

Для примера я буду использовать in-memory хранилище.

Чтобы сгенерировать необходимый набор данных я воспользовался mockaroo.

Кроме того, модуль для работы с бд должен уметь инициализировать хранилище после запуска сервера.

• Warp — Фреймворк для создания веб-сервера на Расте.
• Tokio — Асинхронная среда выполнения для Раста.
• Serde — Библиотека для де/сериализации данных в типизированные данные Раста.

Модели

Первое, что я хочу сделать, это определить свою модель пользователя, а также добавить некоторую структуру в код.

В main.rs определите новый модуль с именем models следующим образом:

mod models;
fn main() { /* Логика */ }

Затем создать новый файл с именем models.rs и добавьте следующее:

pub struct Customer {
    pub guid: String,    
    pub first_name: String,
    pub last_name: String,    
    pub email: String,    
    pub address: String,
}

Так как я разрабатываю API, эта структура данных должна иметь возможность сериализации и десериализации JSON. Я также хочу иметь возможность копировать структуру в хранилище данных и из него, не беспокоясь о проверке заимствования.

Для этого я добавлю оператор drive для структуры пользователя, чтобы использовать пару макросов из библиотеки Serde и пару из Rust. Сейчас models.rs выглядит так:

База данных

База данных для этого API будет являться in-memory(то есть находиться в оперативной памяти и после отключения сервера очистится), которая будет являться вектором структуры Customer. Но хранилище должно быть общим для всех маршрутов, поэтому я буду использовать смарт поинтеры[0] Раста вместе с Mutex[1], чтобы обеспечить безопасность потоков.

Во-первых, добавим в main.rs новый модуль db:

mod db;
mod models;
fn main() { /* Логика */ }

Теперь создадим новый файл db.rs.

В этом файле нужно сделать несколько вещей, но первое, что нужно сделать, это определить, как будет выглядеть хранилище данных.

Наше простое хранилище это лишь вектор структур Customer, но его необходимо обернуть в thread safe ссылку, чтобы иметь возможность использовать несколько ссылок на хранилище данных в нескольких асинхронных обработчиках.

Добавим примерно такое в db.rs:

use std::sync::Arc;
use tokio::sync::Mutex;

use crate::models::Customer;

pub type Db = Arc<Mutex<Vec<Customer>>>;

Теперь, когда мы определили структуру хранилища данных, нам нужен способ его инициализации. Инициализация хранилища данных имеет два результата: либо пустое хранилище данных, либо хранилище данных, наполненное данными из файла.

Инициализация пустого хранилища довольно проста:

pub fn init_db() -> Db {
    Arc::new(Mutex::new(Vec::new()))
}

Но чтобы получить данные из файла, нам придется добавить еще одну зависимость:

• serde_json — Для чтения необработанного JSON

Добавим его в Cargo.toml:

serde_json = "1.0"

Теперь мы можем изменить db.rs следующим образом:

use std::fs::File;
use serde_json::from_reader;

pub fn init_db() -> Db {
    let file = File::open("./data/customers.json");
    match file => {
        Ok(json) => {
            let customers = from_reader(json).unwrap();
            Arc::new(Mutex::new(customers))
        },
        Err(_) => {
            Arc::new(Mutex::new(Vec::new()))
        }
    }
}

Эта функция пытается прочитать файл ./data/customers.json. В случае успеха функция возвращает хранилище данных, загруженное данными клиента, в противном случае она возвращает пустой вектор.

db.rs должен выглядеть примерно так:

На текущем этапе мы имеем модели и настройку базы данных. Теперь у нас нужда в общем связывающем инструменте. Тут в дело вступают обработчики.

Создадим файл handlers.rs и определим его, как модуль в файле main.rs:

mod handlers;

Добавим в handlers.rs несколько импортов:

use std::convert::Infallible;
use warp;

use crate::models::Customer;
use crate::db::Db;

Этот кусок позволяет обращаться к примитивам Customer и Db, которые мы определили ранее, из модуля обработчиков. Также тут мы импортируем модуль warp и перечисление Infallible, которое является типом ошибок, что никогда не могут произойти.

Список пользователей

Обработчик list_customersвобработчик принимает на вход ссылку на хранилище и возвращает Result, который оборачивает JSON-ответ.

pub async fn list_customers(db: Db) -> Result<impl warp::Reply, Infallible> { 
   // ...  
} 

В теле функции нужно реализовать получение данных из хранилища и сериализация их в JSON объект. Для удобства wrap предоставляет функцию, которая преобразовывает вектор в JSON объект.

Строчка let customers = db.lock().await; дожидается блокировки выполнения задачи, чтобы можно было безопасно обратиться к хранилищу.

Строка let customers: Vec<Customer> = customers.clone() клонирует вектор из MutexGuard.

Последняя строка Ok(warp::reply::json(&customers)) оборачивает вектор в JSON объект и возвращает его.

Создание пользователя

Обработчик create_customer принимает на вход объект Customer и ссылку на хранилище. В случае успешного создания возвращает статус код CREATED, в ином случае BAD_REQUEST.

Но прежде нужно обновить импорты wrap'a в файле handlers.rs.

Заменяем строчку use wrap; на;

use warp::{self, http::StatusCode};

Данное изменение позволит использовать перечисление StatusCode, как респонс.

По аналогии с list_customers определяем обработчик create_customer с подобным содержанием:

Получение пользователя

Обработчик get_customer на вход берет guid определенного пользователя и ссылку на базу данных и возвращает JSON-объект, если пользователь найден, иначе вернет заглушку в виде дефолтного объекта пользователя.

Перед этим добавим еще один макрос в структуру пользователя:

По аналогии с другими обработчиками добавляет что-то подобное в код:

pub async fn get_customer(guid: String, db: Db) -> Result<Box<dyn warp::Reply>, Infallible> {
}

Возвращаемый примитив немного отличный от других, потому что на выходе мы получаем либо StatusCode, либо JSON-объект. Так как оба этих примитива реализуют warp::Reply, то мы можем использовать динамическое приведение через dyn.

Обновить пользователя

Обработчик update_customer на вход принимает guid пользователя, измененный объект Customer и ссылку на бд. Возвращает OK, если получилось изменить пользователя, NOT_FOUND в случае, если нет пользователя в хранилище.

Удаление пользователя

Обработчик delete_customer на вход принимает guid пользователя, которого нужно удалить и ссылку на хранилище.

Если удалось удалить пользователя из базы данных, то функция вернет NO_CONTENT, иначе NOT_FOUND.

Теперь у нас все обработчики собраны, теперь присвоим их соответствующим роутам.

В main.rs определим еще один модуль:

mod routes;

Теперь создадим файл routes.rs:

use std::convert::Infallible;
use warp::{self, Filter};

use crate::db::Db;
use crate::handlers;
use crate::models::Customer;

Сначала нам нужна вспомогательная функция для передачи ссылки на хранилище данных в обработчики из маршрутов.

fn with_db(db: Db) -> impl Filter<Extract = (Db,), Error = Infallible> {
    warp::any().map(move || db.clone())
}

Функция позволяет инжектить хранилище в роут и передавать его обработчику. Filter это трейт, который предоставляет функциональность для подбора маршрутов, что являются результатом одного или нескольких методов Filter.

GET /customers

Функция возвращает тип, реализующий трейт Filter. Extract используется, когда происходит совпадение, и возвращается значение Extract.

По сути, функция определяет маршрут, который соответствует запрошенному пути «/customers» и является GET запросом.

Кроме того, чтобы сохранить некоторую работу в будущем, я реализую еще одну функцию, которая будет служить оболочкой для всех маршрутов пользователей. Позже будет легче, когда мы соединим все вместе.

pub fn customer_routes(db: Db) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
    customers_list(db.clone())
}

POST /customers

Этот маршрут добавит нового клиента в хранилище данных, если он еще не существует.

Одна вещь, которую нужно добавить, прежде чем мы реализуем функцию для маршрута, — это вспомогательная функция для извлечения JSON из тела POST запроса.

fn json_body() -> impl Filter<Extract = (Customer,), Error = warp::Rejection> + Clone {
    warp::body::content_length_limit(1024 * 16)
        .and(warp::body::json())
}

Функция будет очень похожа на customers_list, за исключением обработчика. Добавьте в route.rs следующее:

Эта функция определяет маршрут, который соответствует пути «/customers» и является POST запросом. Затем JSON из POST запроса и ссылка на хранилище извлекаются и передаются обработчику.

GET /customers/{guid}

Этот маршрут попытается получить одного клиента из хранилища данных.

В этой функции мы используем макрос path! из wrap, который позволяет передавать путь с переменной.

Это определяет маршрут, который будет соответствовать «customers/{какое-то значение}» и GET запросу. Затем он извлекает хранилище и передает его обработчику.

Одна вещь, которую следует учитывать для маршрутов, заключается в том, что наиболее конкретный маршрут должен быть проверен первым, иначе маршрут может не совпасть.

Например, если вспомогательная функция для маршрутов обновлена таким образом:

pub fn customer_routes(
    db: Db,
) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
    customers_list(db.clone())
        .or(create_customer(db.clone()))
        .or(get_customer(db.clone()))
}

Маршрут get_customer никогда не будет совпадать, потому что они имеют общий корневой путь — «/customers», что означает, что маршрут списка клиентов будет соответствовать «/customers» и «/customers/{guid}».

Чтобы устранить проблему, упорядочите маршрут так, чтобы наиболее точное совпадение было первым. Как это:

pub fn customer_routes(
    db: Db,
) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
    get_customer(db.clone())
        .or(customers_list(db.clone()))
        .or(create_customer(db.clone()))
}

PUT /customers/{guid}

Этот маршрут попытается обновить клиента, если он существует, и вернуть код состояния OK, в противном случае возвращается код состояния NOT_FOUND.

По аналогии с созданием определяем обработчик:

Затем обновим обертку над маршрутом пользователя:

pub fn customer_routes(
    db: Db,
) -> impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone {
    get_customer(db.clone())
        .or(update_customer(db.clone()))
        .or(create_customer(db.clone()))
        .or(customers_list(db))
}

DELETE /customers/{guid}

Последний маршрут просто удаляет клиента из хранилища данных, если он соответствует заданному guid, а затем возвращает код состояния NO_CONTENT, в противном случае возвращается код состояния NOT_FOUND.

Затем обновим оболочку маршрута клиента. После добавления всех маршрутов обертка должна выглядеть так:

На этом все маршруты заканчиваются. Теперь мы можем перейти к связыванию всего вместе.

Файл main.rs собирает все части кода воедино. Он инициализирует хранилище данных, получает все маршруты и запускает сервер. Это также довольно короткий файл, поэтому я просто покажу его целиком:

Мы уже видели первые несколько строк, так что давайте пройдемся по основной функции.

Атрибут функции #[tokio::main] устанавливает точку входа для среды выполнения tokio. Это позволяет нам объявить основную функцию как асинхронную.

Первые две строки main — это просто вызовы функций из наших модулей. Первый инициализирует хранилище данных, а второй получает оболочку маршрутов наших клиентов.

В последней строке используется warp::server для создания сервера, а затем run для запуска сервера на указанном хосте и порте. Мы используем ключевое слово await, чтобы выполнить код до тех пор, пока функция запуска не завершится.

приветики ^//^, тут представлена небольшая подборка библиотек, которые я так или иначе использовал в своих проектах для кастомизации консольного вывода.

1. asciimatics

Asciimatics — это пакет, помогающий людям создавать полноэкранные текстовые пользовательские интерфейсы (от интерактивных форм до анимации ASCII) на любой платформе. Он распространяется под лицензией Apache Software Foundation License 2.0.

Является безусловным фаворитом в больших проектах, которые используют консоль, как ui. Имеет не очень сложную структуру, приятный отклик, возможность анимировать объекты, а также большой ассортимент винджетов и контейнеров.

2. textual

Textual — это полноценный фреймворк TUI (текстовый пользовательский интерфейс) для Python, вдохновленный современной веб-разработкой.

Все обработчики событий асинхронные, из-за чего все виджеты могут независимо обновляться, а также умеют общаться друг с другом отправкой сообщений.

Имеется также поддержка кастомизации виджетов средствами CSS-стилей. Также использует некоторые техники позаимствованные из вью и других веб-фреймворков.

3. rich

Rich это Python библиотека, позволяющая отображать красивый текст и форматировать терминал.

Rich API упрощает добавление цветов и стилей к выводу терминала. Rich также позволяет отображать красивые таблицы, прогресс бары, markdown, код с отображением синтаксиса, ошибки, и т.д. — прямо после установки.

4. questionary

Questionary — это библиотека Python для простого создания красивых интерфейсов командной строки.

Позволяет создавать красивые промпты, которые украсят дефолтный питоновский инпут.

Поддерживаемые промпты:

• Text
• Password
• File Path
• Confirmation
• Select
• Raw select
• Checkbox
• Autocomplete

5. python-prompt-toolkit

python-prompt-toolkit - библиотека, позволяющая создавать интерактивные программы командной строки прямо на Python.

Обилие простых виджетов, подсветка синтаксиса во время печати, автокомплиты, поддержка нажатий мыши и множество других возможностей не оставят данную библиотеку в стороне.