Всем привет.

Пришлось ради одного поста, открыть старый проект на Flet и... он отказался запускаться)

Скорее всего, проблема в том, что ранее я запускал его на Windows, а теперь запускаю на Linux.

Поискав по репозиторию проекта я нашёл решение, которое хочу сохранить тут, мало ли, кому-то кроме меня оно пригодится.

1. Нужно обновить версию Flet до последней:

pip install -U flet

2. Установить пакет libmpv:

sudo apt install libmpv-dev libmpv2

3. Прокинуть симлинк (ссылку) из системного хранилища библиотек в локальное хранилище:

sudo ln -s /usr/lib/x86_64-linux-gnu/libmpv.so /usr/lib/libmpv.so.1

После этого проект запускается без проблем.

Всем привет!

Вчера вышла "одна долгожданная игра", я думаю вы догадываетесь о какой игре речь😉

Так вот, я конечно же решил посмотреть, "как она?". Скачав 154 гига, добавив её в библиотеку Steam и запустив... Я получил ошибку, что не найден Microsoft Visual C++. Оно и понятно, когда устанавливаешь игру из стима, он устанавливает и все необходимые зависимости, тут же игра "сторонняя" и он не знает, что ей нужно что-то ещё, да ещё и на линуксе.

решение было найдено вот тут: https://www.youtube.com/watch?v=Dez4Z0xlZZU

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

1. Скачиваем vc_redist для x86 и x64:
vc_redist_x86: https://aka.ms/vs/17/release/vc_redist.x86.exe
vc_redist_x64: https://aka.ms/vs/17/release/vc_redist.x64.exe

2. Открываем файловый менеджер по пути:

~/.local/share/Steam/steamapps/compatdata

3. Открываем Steam и добавляем оба exe-файла как сторонние приложения.

4. В свойствах каждого, во вкладке "Совместимость", выставляем галочку "... использовать Steam Play" и выбираем "Proton Experemental" или тот, которым вы пользуетесь.

5. Запускаем сперва x86, устанавливаем. Повторяем с x64.

6. Возвращаемся в файловый менеджер. Там появилось две новые директории. Сортируем по дате изменения. Самая свежая это x64, вторая соответственно x86. Дабы они не пропали после удаления из библиотеки Steam, переименовываем их в удобные названия. У меня это vcredist_x64 и vcredist_x86.

7. Открываем в Steam свойства игры, которой требуется Visual C++.
1. На вкладке "Ярлык" отключаем оверлей Steam. С некоторыми играми он вызывает конфликты.
2. Там же в поле "Параметры запуска" вписываем следующую строку, заменив путь до директорий на свой:

STEAM_COMPAT_DATA_PATH=/home/prodream/.local/share/Steam/steamapps/compatdata/vcredist_x86 STEAM_COMPAT_DATA_PATH=/home/prodream/.local/share/Steam/steamapps/compatdata/vcredist_x64 %command%

8. Запускаем игру

Всем привет!

Помимо программирования, я активно изучаю и DevOps направление: Администрирование серверов, контейнеризацию, CI/CD и это только малая часть того, что нужно знать и уметь.

В своих проектах я применяю CI/CD для проверки кода линтером, тестирования (если написаны тесты), сборки и деплоя. На любом из этих этапов может произойти ошибка, и если GitHub уведомляет по почте, то собственный git на базе Gitea так не делает (или я не разобрался), тем не менее, уведомления на почту не очень удобны. Тогда я задался вопросом оповещений в Telegram, что позволит оперативно реагировать на события в пайплайнах.

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

Но на чём его писать? Можно бы было на Python, но я и так всё пишу на нём, хотелось "чего-то нового" и я стал выбирать между GoLang и Rust. Оба языка набирают популярность и имеют свои сильные и слабые стороны. Уж не знаю почему именно, но я выбрал для решения этой задачи Rust.

Начал "как водится", с чтения официальной книги по Rust. Она хорошо написана, но просто так, читая книгу что-то выучить трудно и я решил параллельно начать писать. В процессе, количество открытых вкладок поисковиков, Stack Overflow и других сайтов росло в геометрической прогрессии, это не считая вопросов, которые я задавал чату GPT, прося его объяснить мне в максимальных подробностях.

Результатом стала программа для выполнения в среде GitHub (и не только) Actions под названием Telegram Notify Action. Программа, при срабатывании триггера (они могут быть разные, например always, как понятно из названия, срабатывает всегда, а failure, только при сбое) получает данные из окружения текущего workflow и формирует текст сообщения, а затем отправляет его в Telegram-бота по API.

Если вам интересно, хотите опробовать или просто поддержать поставив "звёздочку", прошу в репозиторий: https://github.com/proDreams/actions-telegram-notifier

Буду рад вашим комментариям и отзывам!

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

Привет всем!

Как у вас проходит предновогодняя суета? Носитесь поди в мыле? Ёлку поставили? Салаты заготовили?
А вот у меня что-то никакого праздника нет, даже гирлянду не повесил)

Перед новым годом нас решил обрадовать хостер сбоями, DDOS'ом и отсутствием быстрого решения. Понадобилось перенести данные с одного сервера на другой, а как водится - бэкапов у нас нет! Сервер с которого надо перенести практически не отвечает, только спустя ~два часа попыток подключиться, удалось на него прорваться и получить данные, но не суть.

Мне подкинули идею сделать sh-скрипт и даже показали пример, по выгрузке бэкапов на S3-хранилище и тут я задумался, что у меня на сервере порядка 10ти сервисов, а есть ещё и другие сервера... Писать для каждого случая свой скрипт, добавлять в cron, управлять ими. Муторно и монотонно, не находите?

Тогда я решил, что это отличная возможность продолжить практику с Rust. И меньше чем за сутки написал альфа версию утилиты для создания бэкапов. Суть вт ом, что в ней зашиты команды для создания бэкапов из локальных БД и их докер версий, а также бэкап указанной директории. Всё, что необходимо, это прописать желаемые бэкапы в конфигурационном файле, там же указать данные для подключения к S3.

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

Репозиторий проекта на GitHub: https://github.com/proDreams/universal-backup-restore

Буду раз отзывам и звёздочкам, спасибо!

Всех с Наступающим Новым Годом!

Всем доброго утра =)

Недавно узнал о новой, "хайпующей", IDE - Zed Editor. Выделяется в первую очередь тем, что делают её авторы весьма популярного редактора Atom, и, что написан он на Rust. О самом редакторе поговорим в другой раз на Салфетке, как освоюсь (или забью).

Сейчас хочу описать решение проблемы с которой я столкнулся при использовании редактора "из коробки".

Проблема: редактор "не видел" установленные библиотеки в виртуальном окружении, а также в упор не видел модули/функции/переменные из других файлов проекта. Часы гуглежа и чтения Issue на Github привели только к решению первой проблемы, но не второй. Однако, я таки нашёл решение!

1. pyrightconfig.json
Первое, что необходимо сделать - это добавить pyrightconfig.json в корень проекта со следующим содержимым:

{
  "venvPath": ".",
  "venv": ".venv"
}

Тут указываем:
- venvPath - путь до директории с виртуальным окружением, либо точку, если оно находится в корне проекта.
- venv - название директории с виртуальным окружением.

2. python-lsp-server
Вторым шагом будет установка в виртуальное окружение сервер pylsp. Именно он отвечает за работу с файлами проекта.

Достаточно выполнить команду:

pip install 'python-lsp-server[all]'

Либо, добавить в dev-зависимости менеджера пакетов poetry или uv:

# poetry
poetry add -D 'python-lsp-server[all]'

# uv
uv add --dev 'python-lsp-server[all]'

Примечание к пунктам 1 и 2
Это необходимо делать в каждом проекте. Также, можно установить pylsp глобально и указывать его, но мне лень тестировать и это.

3. Конфигурация Zed
Открыть редактирование файла настроек, либо через главное меню, либо нажав CTRL+, (если настройки сочетаний клавишь дефолтные).

Там добавить следующий блок:

 "lsp": {
    "pyright": {
      "settings": {
        "python.analysis.diagnosticMode": "workspace",
        "python.pythonPath": ".venv/bin/python"
      }
    }
  }

Заменив занчение python.pythonPath на путь к интерпретатору питона в виртуальном окружении, если оно находится не в корне проекта.

4. Перезапуск
Перезапустить Zed.

После этого, всё должно заработать корректно. Если нет, то ну я даже не знаю)

Бонус: Мой конфиг
Это скорее для меня самого, мало ли придётся переустановить.

{
  "base_keymap": "VSCode",
  "ui_font_size": 18,
  "buffer_font_size": 18,
  "theme": "JetBrains New Dark",
  "icon_theme": {
    "mode": "dark",
    "light": "JetBrains New UI Icons (Light)",
    "dark": "JetBrains New UI Icons (Dark)"
  },
  "autosave": "on_focus_change",
  "languages": {
    "Python": {
      "language_servers": ["ruff", "pylsp", "pyright"],
      "format_on_save": "on",
      "formatter": [
        {
          "code_actions": {
            "source.organizeImports.ruff": true,
            "source.fixAll.ruff": true
          }
        },
        {
          "language_server": {
            "name": "ruff"
          }
        }
      ]
    }
  },
  "lsp": {
    "pyright": {
      "settings": {
        "python.analysis.diagnosticMode": "workspace",
        "python.analysis.typeCheckingMode": "basic",
        "python.pythonPath": ".venv/bin/python"
      }
    },
    "ruff": {
      "initialization_options": {
        "settings": {
          "lineLength": 120,
          "lint": {
            "extendSelect": ["I"]
          }
        }
      }
    }
  }
}

В догонку решили попробовать Sora...

Пока определённо не очень. Либо я не понял, как надо)

Всем привет!

Я на линуксе уже месяцев 10 (никого не призываю, сидите на винде, оно вам не нужно!) и всё шло вроде хорошо. Система работала без проблем, работа работалась удобно, пока не случился ... апдейт.

У меня была Nobara (основана на Fedora) и у неё режим выпуска Rolling Release, т.е. обновляется постоянно, а не как LTS дистрибутивы, раз в несколько месяцев.

Так вот, ничто не предвещало беды. Очередной пак обновления включал драйверы Nvidia. Установил, перезагрузил и меня встречает прелестный белый экран Gnom'а с ошибкой "что-то пошло не так".

Ночь убил на попытки восстановления. Сносил дрова, ставил старее, переключился на X11 вместо Wayland, всё тщетно.

В итоге пришлось на целую неделю перейти на Windows 11 (елинственная флешка с системой была с виндой). И после почти года на линуксе, это было не просто. В целом что там, что там управление системой одинаковое, но разница в мелочах. Для Docker'а нужна виртуалка WSL, Qdrant отказался работать в контейнере, хотя на линуксе работал корректно и куча других мелких проблем с библиотеками и совместимостью.

В итоге, доделав дела которые были, я вернулся на линукс. На этот раз выбрал Cachy OS (на базе Arch).
Что по первым впечатлениям:
- Работает сильно быстрее федоры. Начиная установкой пакетов, заканчивая самой системой. Просто летает.
- После установки сразу актуальные драйвера, Wayland и Steam со специальной версие Cachy Proton, оптимизированной под эту ОС.
- Хоть Arch и популярен, но основные линукс сборки приходятся на RPM или DEB-пакеты, но в репозитории AUR есть почти всё, что нужно, собранное из DEB-пакетов.

Как-то так. Интересно, сколько проживёт эта установка?

Есть идеи? =)

Всем привет!

У GitVerse совместно с Хабром проходит конкурс Open Source-проектов «Код без границ». Я решил запрыгнуть в этот поезд со своим проектом ReVu, о котором расскажу подробнее уже в этот четверг.

Одним из условий конкурса является размещение проекта в репозитории на GitVerse.
Я решил воспользоваться ситуацией и «убить двух зайцев»:

- Принять участие в конкурсе
- Интегрировать GitVerse в свой проект

Но, как это часто бывает, всё оказалось не таким простым, как кажется. Об этом — данный пост.


Что понравилось?

1. Своя платформа. Кто бы что ни говорил, но нам нужны собственные аналоги. Сейчас GitHub блокирует доступ для пользователей из Крыма — что мешает однажды расширить эти ограничения? Наличие альтернативы внутри страны — полезно и важно.

2. Облачные раннеры «из коробки». Это удобно: можно запускать простые CI/CD-пайплайны без настройки собственного раннера. Да, есть лимиты, но они есть везде. Плюс — совместимость с GitHub Actions: мои воркфлоу заработали почти без изменений.

3. Приятный интерфейс. Возможно, субъективно, но внешний вид GitVerse современный и аккуратный — работать комфортно, «глаз не режет».

На этом, пожалуй, плюсы заканчиваются. Дальше — обычный git-хостинг без каких-то выдающихся фич.


Что не понравилось?

Здесь уже больше проблем.

1. Ограничения облачных раннеров. Образ сильно урезан: нет даже базовых зависимостей, например Node.js (а он нужен многим Actions). Нет доступа к Docker-сокету — собрать Docker-образ на стандартном раннере невозможно, придётся подключать свой.

2. Вебхуки и безопасность.

2.1. Нет подписи вебхуков. GitHub и Gitea подписывают события через HMAC SHA-256, что позволяет проверить целостность данных. У GitVerse этого нет — можно только добавить заголовок Authorization.

2.2. Некорректные ссылки в вебхуках. Вместо нормальных публичных URL вида https://gitverse.ru/.../... приходят технические вроде http://gitea-http:3000/.../.... Такое ощущение, что «вышли в прод, а настроить забыли».

3. Слабое публичное API. GitVerse основан на Gitea — и это нормально, но при этом доступное API сильно урезано. В Gitea из коробки большой и удобный API, а здесь — «обрезок» без нужных эндпоинтов. К тому же API закрыто по умолчанию: чтобы использовать его, нужно подать заявку. Когда её рассмотрят — неизвестно.

Это то, что я заметил за несколько часов работы. Для кого-то всё перечисленное может быть не критично — основной функционал git-хостинга работает, а я, может, придираюсь.

Я написал письмо в поддержку с описанием проблем и вопросов. Ответ уже пришёл: «взяли в работу и свяжутся позже». Посмотрим, что ответят.