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

Поделитесь в комментариях)

Upd. Спасибо за комментарий, важная оговорка: проект работает локально на вашем компе, без утечек в инет)

• все локально и приватно: можно работать с документами, кодом и другими важными данными;

• через одну панель можно подключить голосовых помощников, агентов вроде Hermes, RAG, поиск, генерацию изображений и десятки других инструментов;

• без облачного сервиса. Без подписки.

Как всегда, ничего сложного, используются две библиотечки Rich + Prompt Toolkit. Вся эта красота хранится в отдельном модуле console, легко сможете разобраться, переделать, или подчерпнуть что-то для своих проектов. Кода там совсем немного.

Репозиторий: AgentAnufry

Есть идея в отдельной ветке Ануфрия запилить “кибербезопасника”, вырезав все лишнее и напихав скилов под инструменты Kali Linux. Мне кажется, тут LLM может проявить себя с хорошей стороны, если грамотно предоставить инструментарий.

Возможно что-то похожее уже кто-то реализовывал? Если да, поделитесь информацией об успехах.

P.S.: Ануфрий - это мой проект простого конструктора для создания собственных ассистентов на Python.

https://github.com/akdengi/sklad-cz

Что нового:

• Выбор товарной группы для работы в настройках (одиночный выбор из справочника). Реализованы 22 доступные группы (исключены алкоголь, табак, мех, ветпрепараты и др.)

• Запрос и отображение баланса денежных средств в ЧЗ на дашборде. Кнопка «Обновить баланс» для ручного обновления.

• Загрузка данных МОД из API Честный Знак по кнопке. Автоматическое заполнение адреса и FIAS ID. Предупреждение при отсутствии МОД со ссылкой на ЛК ЧЗ.

• Сканирование: проверка GTIN КМ для SKU, авто-определение правильного SKU, онлайн-проверка статуса ЧЗ сразу после добавления

• При импорте теперь выдает детальный отчёт об ошибках с модальным окном и экспортом в CSV (дубликаты, структура, GTIN, статус ЧЗ).

• Продажа: блокировка поиска по GTIN/Артикулу/EAN для товаров с маркировкой (только поиск по КМ).

• Склады: улучшенное отображение — таблица SKU с колонками Остаток/Продано.

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

А там глядишь и до заказа КМ доберусь и вводе в оборот :)

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

Начал с малого. Вынес всю бизнес-логику в отдельные функции которые не знают ничего про Telegram. Просто принимают данные, возвращают результат.

python

# Не так
async def handle_payment(message: types.Message):
    amount = int(message.text)
    if amount > 10000:
        await message.answer("Сумма слишком большая")

# А так
def validate_amount(amount: int) -> tuple[bool, str]:
    if amount > 10000:
        return False, "Сумма слишком большая"
    return True, ""

async def handle_payment(message: types.Message):
    is_valid, error = validate_amount(int(message.text))
    if not is_valid:
        await message.answer(error)

Теперь validate_amount тестируется обычным pytest без всяких моков. Вызываешь функцию, проверяешь результат.

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

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

Кто тестирует ботов, как организуете?

1. В Остатках в карточке товара появилась кнопка «Списать», позволяя сделать быстрое списание с нулевой ценой и выбором причины: утеря, собственные нужды, производственные цели, безвозмездная передача, отзыв с рынка. Данные нужно подавать также вручную, но для учета полезно.

2. Добавлен вид документа в продаже: поле «Вид док-та» в шапке заказа (Прочее, УПД, Товарная накладная, Акт приёма-передачи, Кассовый чек).

3. Появилась кнопка «Скачать КМ в CSV» в корзине Продаж для скачивания КМ в формате «для ввода/вывода из оборота» для вставке в ЭДО при передаче УПД.

4. Дропдаун «Статус» теперь показывает статус ЧЗ для проданных товаров.

5. Появилась возможность выделить и произвести массовую проверку статуса ЧЗ для выделенных товаров (чекбоксы + кнопка) на вкладках Остатки, Продано, Вывод из оборота.

6. Появилась колонка «Статус в ЧЗ» в таблицах Остатки и Вывод из оборота

7. Сделано автоподтверждение отчёта о выбытии при статусе ЧЗ равном «Выбыл» (RETIRED/WITHDRAWN/WRITTEN_OFF)

8. Сделано сохранение активной вкладки при перезагрузке страницы

9. Введена новая логика быстрой продажи: в шапку заказа: номер заказа, склад списания, дата продажи, добавление нескольких товаров по КМ/артикулу/EAN-13 с ценой за позицию в корзину с одинаковым номером заказа, КМ для Маркетплейсов отображается в корзине и копируется кликом, сделан Live-поиск при вводе кода с полной информацией о товаре.

ПО я писал для своей товарной группы «Игры и игрушки», но оно должно подходить и для других товарных групп потребительских товаров.

Сразу напишу про API: авторизация по ЭЦП и получение общего статуса по КМ все еще ведется по 3 версии API Честного Знака, как и например работа с МОД, а что-то уже работает только по 4 версии API (например ввод-вывод из оборота).

Делимся подборкой статей от Евгения Бартенева, эксперта курсов Практикума и разработчика с 20-летним опытом. А ещё он активно занимается созданием образовательного контента: является автором и техлидом курса «Python-разработчик», пишет статьи и проводит бесплатные мок-интервью для всех желающих в рамках проекта Boreesych.

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

Особенности Python, о которых вас точно спросят на техническом собеседовании. Часть 2. Евгений выпустил продолжение, так как первая часть вызвала оживлённое обсуждение: в комментариях читатели делились собственным опытом и задавали отличные уточняющие вопросы. В этой части ещё больше подводных камней Python — уже традиционно без абстракций и банальщины.

Строки в Python: всё не так просто, как кажется. Начинающим разработчикам строки обычно кажутся едва ли не самым простым, что есть в языке программирования, но для Python это не совсем так. Евгений разбирает, какие бывают строки, чем они отличаются друг от друга, какие возможности дают и какие подводные камни могут встретиться в работе с ними. Здесь и о базовом использовании, и о важных деталях, которые стоит помнить каждому разработчику. 

От джуна к эксперту: как карта навыков и план развития помогают профессиональному росту Python-разработчика. Евгений размышляет, почему «стать мидлом, потом синьором» — плохая цель, которая не помогает расти. Затем рассказывает, что такое план профессионального развития, зачем он нужен и как его использовать на собеседованиях, в обучении и в реальной работе. А также делится примером карты навыков и шаблоном плана.

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

Если хотите освоить профессию Python-разработчика с нуля, сделать это можно на курсе «Python-разработчик» в Практикуме. Первые 30 уроков доступны бесплатно: вы попробуете себя в роли разработчика, познакомитесь с образовательной платформой и поймёте, подходит ли вам курс.

Суть: собесил сегодня чувака на инженерную позицию. Туда-сюда, вроде все складно, тимлиду вроде нравится. Потом дали мне слово, как софтверному инженеру, и я задал ровно два вопроса, после которых все стало понятно.

1 - чувак говорил, что у него есть хоум лаба, но не смог рассказать из чего она состоит (контейнеры/виртуалки/гипервизор).

2 - чувак показал свой пет-проект, но не смог рассказать как он работает под капотом.

Почему? - потому что он "кнопкодав", "оператор ЛЛМ" - называйте как хотите.

Это очень опасная тенденция, все больше людей называют себя "архитекторами" приложений, не понимая основ технологий которые их ЛЛМ пытается применять.

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

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

Бэкенд наоборот поддерживает порядок и структурность. Меньше экспериментов и больше проверенных решений, самое то для "сделал работу - пошел спокойно домой".

Сегодня поделюсь своим проектом, где использовал возможности открытых моделей LLM для создания автоматизированного конвейера по переводу англоязычных pdf-файлов в русскоязычные pdf. Как человек, интересующийся именно технологиями в области ИИ мне особенно было интересно максимальное приближенное к оригиналу сохранение содержимого переведенного материала, включая схемы, математические формулы, блоки кода (python) и bash-команд, рисунков (само собой), сохранение сносок, ссылок и пр. метаданных. Целью проекта было применение всевозможных доступных стеков и программ, использующих LLM в конкретной практической задаче. И как оказалось, на первый взгляд, простая задача перевода, с которой современная LLM, созданная и обученная на архитектуре трансформеров справляется на сегодняшний день блестяще, для pdf-формата оказалась не совсем простой (но и не скажу, что особо сложной).

О выборе программного стека технологий. Здесь во многом все определило глубина моих познаний и практических умений работать с LLM-моделями и тем оборудованием (потребительским, конечно), которое имеется дома. Поэтому, исходя из пары-тройки (пары) вычислительных узлов (ноутбуков) в домашней локалке мой выбор определил следующие программные и аппаратные компоненты.

Программные компоненты. Прежде всего это среда выполнения wsl. Просто работает в windows, удобна мне как новичку. В wsl установка обычной env стандартным python. И далее уже конкретные ПО для выполнения задачи перевода pdf на русский. Тут пришлось почитать в сети что есть свободное (исходя из цели использования только открытого ПО и LLM, чтобы оценить уровень их развития). Были опробованы такие программы как Docling, Marker-pdf и еще какую-то). В итоге, для извлечения из pdf в markdown формат я использовал Marker-pdf. У него имеется целый набор специализированных ocr-моделей для парсинга содержимого pdf. Marker в режиме конвейера осуществляет извлечение в указанную папку все содержимое исходного pdf в виде отдельных jpg-файлов, файла метаданных и итогового англоязычного .md файла. Для обратного процесса конвертации переведенного на русский язык ru.md я использовал WeasyPrint и Pandoc. Мой выбор - Pandoc. Сложнее, но поддержка xeLatex и куча настроек через опции командной строки и переменных окружения wsl. Pandoc - единственное ПО в моем конвейере, которое не использует LLM. И собственно, середина - перевод. Готовый скрипт на python. Перевод разбитых на части (chanks) в endpoint LLM - requests.post. Фишкой является url, который через специальный балансировщик, управляющий вычислительными узлами в локалке отправляется в requests.post. Получается параллельный перевод на нескольких узлах с  развернутыми OpenAI-совместимыми LLM. Количество узлов - сколько найдется в домашней ИИ лаборатории))). До и после отправки на перевод в LLM - чистка регулярками от различных костылей и защиты от перевода не нужных элементов (чистка колонтитулов, пагинация, сглаживание двойных переносов строк, изоляция спец. блоков от LLM блоков кода, мат. формул, кода внутри строк, приведение кода к pep8), подготовка переведенного _ru.md к сборке pdf-файла в Pandoc. В итоге - pipeline в 3 шага: Marker-pdf, Скрипт-переводчик на python, Pandoc.

Все вместе также можно запустить скриптом bash-сценария:

Использование: ./pipeline.sh <path_to_input_pdf> <output_path> [page_range]

Пример1: перевод всего Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings

Пример1: перевод первых 21 страниц Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings 0-20

Репозиторий на github DemonODG/pdf-translator: English-to-Russian PDF Translation Pipeline

Это мой первый пост на тему применения современных LLM моделей в различных практических задачах. Если это вызовет интерес в более подробном описании данного pipeline - напишу статью поподробнее.

Всем добра!

Привет, Хабр! Продолжаем нашу рубрику с быстрыми ответами на некоторые часто встречающиеся вопросы. Сегодня разберем такую проблему: проекты постоянно ломаются из-за конфликтов зависимостей. Что выбрать для новых проектов и как сделать так, чтобы код работал одинаково, в том числе в CI?

Обычно начало всех проблем — смешение глобальных и локальных пакетов или отсутствие фиксированных версий библиотек. Главный совет: у каждого проекта должно быть собственное окружение с явно указанными зависимостями и сохраненным lock‑файлом в репозитории.

Если говорить о базе, то это связка venv и pip. Плюс она встроена в сам Python. Вы вручную создаете окружение, устанавливаете нужные пакеты и фиксируете их в requirements.txt. 

Но подход со временем может стать неудобным — особенно когда в проекте десятки зависимостей и несколько разработчиков. Поэтому, на смену ручным методам пришел Poetry. 

Сейчас это, пожалуй, наиболее сбалансированное решение: он создает и управляет окружениями, отслеживает версии, собирает wheel‑пакеты и умеет публиковать их в PyPI. Lock‑файл (poetry.lock) обеспечивает воспроизводимость сборок, а сам формат pyproject.toml — это стандарт. В итоге вы получаете чистое окружение, детерминированные зависимости и понятное поведение CI.

Вот пример рабочего цикла:

python -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install poetry
poetry install
poetry run pytest

В CI чаще используют схему с экспортом зависимостей:

poetry export -f requirements.txt --without-hashes -o reqs.txt
pip install -r reqs.txt
pytest

Отдельно стоит упомянуть uv — относительно новый инструмент, созданный командой Astral (авторы Ruff). Он написан на Rust и совместим с Python. По сути, это те же функции pip, venv и частично poetry, но быстрее. От Poetry он отличается отсутствием публикации пакетов, но при этом умеет сам устанавливать и менять версии Python через .python-version. 

UV работает с pyproject.toml и имеет собственный uv.lock. Может использоваться вместе с Poetry, но лучше создавать единый uv.lock для строгой воспроизводимости. Для CI это удобно, вы пишите:

pip install uv

Далее есть два варианта:

• uv venv — создает виртуальное окружение. Это аналог python3.13 -m venv .venv, но работает быстрее и с автоустановкой версии Python.

• uv init — помимо .venv, добавляет шаблон проекта с pyproject.toml для зависимостей, Git-репозиторий и базовые файлы. Идеально для нового проекта.

И окружение в CI полностью совпадает с локальным, а билд воспроизводится без сюрпризов. Но чаще всего комбинируют два решения: Poetry для разработки и uv — для быстрых сборок и деплоймента.

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Бывает так, что после обновления OpenSSL часть HTTPS-вызовов к внешним сервисам падает с ошибкой ssl.SSLError. Сейчас разберемся, как настроить Python, чтобы handshake проходил успешно и соединение оставалось безопасным.

После апдейтов OpenSSL часто отключают старые протоколы и слабые шифры — старые серверы не проходят handshake. Решение на клиенте — явно создать ssl.SSLContext, задать минимальную версию TLS и, при необходимости, набор шифров, а затем передать этот контекст в HTTP-клиент (например, httpx).

import ssl
import httpx

ctx = ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
ctx.minimum_version = ssl.TLSVersion.TLSv1_2
ctx.set_ciphers('ECDHE+AESGCM:!ECDSA:!aNULL:!eNULL')

with httpx.Client(verify=ctx, timeout=10.0) as client:
    r = client.get('https://api.example.com')
    r.raise_for_status()
    print(r.status_code)

В коде мы указываем TLSv1_2 как минимальный порог. Это удобно: если сервер уже поддерживает TLS 1.3, все само заработает на самой новой версии. Но если какой-то внешний сервис еще не успел обновиться, соединение не разорвется, и все продолжит работать на стабильном 1.2. Так мы получаем универсальный код, который не сломается при работе со старыми API.

Для отладки TLS handshake применяйте openssl s_client -connect host:443 -tls1_2 чтобы увидеть, какие шифры поддерживает сервер. Временное ослабление minimum_version даст совместимость, но хуже для безопасности — лучше апгрейдить серверную часть. Сертификаты и ключи храните вне кода (секреты/volumes), не логируйте их, и при работе в контейнерах используйте безопасные механизмы передачи секретов.

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Писал на Python и честно говоря asyncio воспринимал как магию. Работает и ладно.

Пока однажды бот не завис.

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

Начал разбираться. Оказалось я вызывал синхронную функцию прямо внутри async хендлера. requests.get внутри async def. Это блокирует весь event loop. Все корутины ждут пока эта одна функция не завершится.

Решение простое: либо заменить requests на aiohttp, либо обернуть синхронный вызов через asyncio.to_thread. Второй вариант проще когда менять библиотеку лень:

python

result = await asyncio.to_thread(requests.get, url)

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

Кто сталкивался с похожим, как отлаживали?

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

Итак, допустим, агент спустя время начинает расти по памяти и в итоге все падает. Где копать и как временно ограничить ущерб, пока ищете утечку?

Первое, что нужно сделать — измерить и локализовать. tracemalloc показывает, какие строки выделяют больше всего памяти, gc — количество объектов. 

Часто проблема в неограниченных кэшах, списках или в C-расширениях. Сначала стоит включить tracemalloc, дать процессу поработать и снять снапшот:

import tracemalloc
tracemalloc.start()
# после нагрузки
snapshot = tracemalloc.take_snapshot()
top = snapshot.statistics('lineno')[:10]
for stat in top:
    print(stat)

Параллельно делайте gc.collect() и логируйте число объектов len(gc.get_objects()), чтобы увидеть рост. На время расследования применяйте эксплуатационные меры: для WSGI-сервисов используйте Gunicorn с --max-requests и --max-requests-jitter, чтобы процессы периодически перезапускались и не накапливали мусор. А в контейнерах ставьте cgroup-пределы (--memory) и настраивайте restart-политику, чтобы платформа автоматически перезапускала упавшие поды.

Пример запуска Gunicorn:

gunicorn myapp:app --workers 4 --max-requests 1000 --max-requests-jitter 50

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

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

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

По запросу ИИ-инструмент может адаптировать резюме под конкретную вакансию и подготовить сопроводительное письмо. При этом решение не отправляет отклик автоматически: пользователь должен самостоятельно проверить документы и решить, подавать ли заявку.

Сервис задуман как бесплатный. Для поиска вакансий он использует веб-агента TinyFish, а для анализа — бесплатные модели через OpenRouter. По умолчанию система переключается между Llama, Nvidia Nemotron, Google Gemma 4 и Alibaba Qwen3, если у одной из моделей заканчивается лимит. Вместо OpenRouter можно подключить Claude Code и API Anthropic, но в этом случае понадобится подходящая подписка или оплаченные токены.

Разработчик отдельно описал меры защиты данных. Файл с настройками и ссылкой на локальное резюме исключён из Git, поэтому его нельзя случайно опубликовать вместе с кодом проекта. Однако содержимое резюме все равно передаётся моделям, подключённым через OpenRouter. Тем, кто не хочет отправлять данные через этот сервис, автор предлагает использовать Claude Code.

По умолчанию autopilot‑jobhuntt настроен на поиск вакансий для разработчиков, но список профессий, компаний и требований можно изменить — нужно отредактировать файл конфигурации проекта.

Делал платежи в Telegram-боте. Нативные, через sendInvoice и ЮKassa.

Всё настроил: токен от BotFather получил, инвойс отправляется, кнопка оплаты появляется. Пользователь нажимает - и платёж падает с ошибкой. Молча. Без подробностей.

Payment failed

И всё. Telegram не говорит что именно не так.

Полез гуглить. Первая мысль - provider_token неверный. Проверил три раза, скопировал заново. Нет, токен правильный.

Потом решил что проблема в суммах - они передаются в копейках, не в рублях. 500 рублей = 50000. Перепроверил, у меня было правильно.

Потом подумал на webhook - может HTTPS не настроен как надо. Потратил минут сорок на проверку сертификата, перенастройку ngrok. Всё работает, но платежи всё равно падают.

Уже хотел идти спать, случайно наткнулся на строчку в документации:

Your bot must reply to this query in 10 seconds

Это про pre_checkout_query. Когда пользователь нажимает «Оплатить» - Telegram сначала отправляет боту запрос на подтверждение. Бот должен ответить в течение 10 секунд. Если не ответил - платёж автоматически отклоняется.

У меня хендлера для этого не было вообще. Бот просто молчал.

Добавил три строки:

python

@dp.pre_checkout_query()
async def pre_checkout(query: types.PreCheckoutQuery):
    await query.answer(ok=True)

Платёж прошёл с первого раза.

Два часа отладки из-за трёх строк кода которые я не написал.

Если кто-то тоже делает платежи в Telegram-боте и получает молчаливый отказ - проверьте pre_checkout_query первым делом, до всего остального.

В доке Albumentations появился отдельный раздел про мой AlbumentationsX MCP - https://albumentations.ai/docs/integrations/mcp/

Теперь есть официальный integration guide, где показано, как ты можешь подключить MCP-сервер к AI-assistant’у и использовать его для нормального HITL workflow вокруг CV-аугментаций: подобрать pipeline, провалидировать его, отрендерить локальные previews, сравнить baseline и candidate, дать feedback вроде too_noisy:high и экспортировать финальный pipeline.

Приятно видеть, что проект стал частью экосистемной документации Albumentations. 🙂

AlbumentationsX MCP это конечно же не замена Python API, а assistant-facing review layer для тех случаев, когда ты хочешь быстрее и безопаснее работать с augmentation pipelines.

Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.

Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.

для тех, кто пишет код в VS Code, не помнит наизусть флаги git filter-repo и считает, что IDE — нормально. Если ты из лагеря «настоящие программисты сидят в vim и пишут всё в Makefile» — просто пролистай

git-private2public как .gitignore, но чтобы сделать зеркало приватного репо одной git push.

Что это

CLI-тулза. Держит два репо в синхроне: приватный (ваш рабочий бардак) и публичный (чистая версия). При пуше автоматически вычищает секреты и обновляет публичный mirror.

Конфиг — папка .gitpublic/, как .gitignore. По одной маске на строку, без YAML.

.gitpublic/
  config      — source / target / push
  ignore      — что НЕ публиковать
  replace     — что заменить (==> без кавычек)
  scan        — что не должно попасть, иначе падаем
  allow       — но конкретно эти можно пропускать в пуш,  

Файла нет → настройки нет. Просто.

Автопуш через git hook

pip install git-private2public
cd ~/my-private-repo
git-private2public init

init создаёт пять пустых файлов с закомментированными примерами. Дальше правите то, что нужно:

Easy — только ignore:

.env
secrets/
*.key
credentials.json

Medium — добавляете replace:

10.0.0.5          ==> 203.0.113.5
real-token-here   ==> ***

Hard — добавляете scan (защита от факапов):

# scan
regex:github_pat_[A-Za-z0-9_]{30,}
regex:192\.168\.

Если в коде найдётся паттерн из scan — publish падает, ничего не пушится.

git-private2public scan      # dry-run
git-private2public publish   # реальный пуш

Автопуш через git hook

Это та фича, ради которой я и начал. Никакого CI, никаких GitHub Actions.

git-private2public hook enable

Ставит pre-push хук. Теперь обычный git push — отправляет в приватный репо и автоматически чистит-пушит в публичный mirror.

git-private2public hook status    # проверить
git-private2public hook disable   # выключить

Работает офлайн, на любом хостинге.

Почему не git filter-repo или BFG

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

Не нашёл — написал.

Установка (ещё раз, коротко)

pip install git-private2public

Если pip не вариант — single-file: скачал git_private2public.py, chmod +x, готово (нужны git-filter-repo и pyyaml).

Ссылки

• Репо: https://github.com/megamen32/git-private2public

• MIT, форкайте, шлите PR

• README на русском: README.ru.md

TL;DR

pip install git-private2public → init → редактируешь .gitpublic/ignore → publish. Если хочешь автопуш — hook enable.git push. Всё.

• 840 различных OSINT-инструментов для анализа сайтов, соцсетей, других ресурсов, хостингов, доменов и даже физических устройства;

• все сервисы работают по одному клику. При этом интерфейс интуитивно понятен;

• отчёты предоставляет в JSON, CSV, HTML и Markdown форматах;

• без ограничений, без дополнительных установок.