Привет всем!

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

Перед новым годом нас решил обрадовать хостер сбоями, 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-хостинга работает, а я, может, придираюсь.

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