Что такое pylsp? Никогда не сталкивался. Я знаю людей, которые в vim используют pyright, basedpyright, ruff LSP, про pylsp никогда не слышал.

У pyright конфиг хранится в pyproject.toml, не знаю, реагирует ли на него VS Code, по идее как бы должен… Но не пользуюсь VS Code, так что не уверен.

Если хочется единый стиль, то это неверный подход. Верный подход - использовать линтеры и другие проверки (например, mypy, pyright), например, в pre-commit и (обязательно) в CI/CD.

Что такое pylsp? Никогда не сталкивался. Я знаю людей, которые в vim используют pyright, basedpyright, ruff LSP, про pylsp никогда не слышал.

примерно то же что и pyright

Если хочется единый стиль, то это неверный подход. Верный подход - использовать линтеры и другие проверки (например, mypy, pyright), например, в pre-commit и (обязательно) в CI/CD.

Это не поможет при написании кода. pylsp нужен для навигации по кодовой базе.

У pyright конфиг хранится в pyproject.toml, не знаю, реагирует ли на него VS Code, по идее как бы должен… Но не пользуюсь VS Code, так что не уверен.

Похоже у pylsp тоже, да. VS Code на него реагировать не нужно, достаточно чтобы это сделал pylsp. Сейчас проверю.

примерно то же что и pyright

Да нет, выглдяит как намного более старые и кондовые технологии.

Это не поможет при написании кода. pylsp нужен для навигации по кодовой базе.

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

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

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

Я не понимаю, о чем ты. Для навигации по питоновом коду есть что-то лучше LSP, что работает и в neovim, и в vscode?

pyright умеет pyproject.toml из коробки, в отличии от pylsp:

[tool.pyright]
venv = ".venv"
venvPath = "."

Работает везде. Проблема решена.

Я не понимаю, о чем ты. Для навигации по питоновом коду есть что-то лучше LSP, что работает и в neovim, и в vscode?

Я имею в виду, что мне известен только один хороший LSP - pyright. Не слышал, чтобы были лучше него.

Имхо каждый должен иметь возможность настроить свою среду разработки так, как ему удобно, без всяких жестко фиксированных pylsp. Общие проверки нужно выносить в CI, с возможностью повторить CI-пайплайн локально вручную или через pre-commit, для тех, кому хочется.

Конечно, есть grep

GREP-МАНИФЕСТ

против LSP-навигации по коду

Тезис

Код — это текст. Навигация по тексту должна быть текстовой. grep/rg дают истинную, мгновенную, воспроизводимую картину. LSP для навигации избыточен, хрупок и лжёт, когда индекс устаревает.

Почему grep

1. Скорость: O(размер текста), без демонов и прогрева индексов.
2. Надёжность: смотрит в файл, а не в кеш. Нет рассинхронизации.
3. Универсальность: любой язык, любой генерат, любой билд-стадж.
4. Комбинаторика: пайплайны UNIX решают 90% задач навигации.
5. Контроль: точные паттерны, детерминированные результаты, легко ревьюить.
6. Портируемость: локально, по SSH, в CI, в контейнере, в монорепо.

Почему LSP плох

• Хрупкая индексация: одна сломанная зависимость → “нет определения”.
• Ложные гарантии: “перейти к определению” ведёт в кеш, не в правду файла.
• Цена: память, CPU, сетевые RPC, фоновые краши.
• Полиглот-страдания: один сервер на язык, конфликт версий, ад.
• Плохая деградация: частично собранный проект = слепая навигация.
• Непрозрачность: JSON-RPC внутри, трудно отладить и воспроизвести.

Принципы навигации текстом

1. Источник истины — git ls-files + рабочее дерево.
2. Сначала грубый поиск по идентификатору, затем уточнение контекста.
3. Превью до перехода. Переход по координатам file:line.
4. Скриптуемость выше кликов. Команда = артефакт, её можно положить в repo.
5. Никаких демонов. Только stdin/stdout.

Базовые приёмы

Опорный набор: rg/git grep, fzf, sed/awk, xargs, fd, ctags как опциональный индекс.

Поиск определения символа:

rg -n --pcre2 -w "^(\\s*(fn|def|class|struct|type|interface)\\s+)?<SYMBOL>\\b" \
  --glob '!*.min.*' --glob '!dist/*' --hidden

Поиск всех упоминаний:

rg -n -w '<SYMBOL>' $(git ls-files)

Поиск вызовов функции:

rg -n --pcre2 '\\b<SYMBOL>\\s*\\('

Ограничение по языку/папке:

rg -n -w '<SYMBOL>' -g '!tests/**' -g '*.go' -g '*.ts'

Живой превью с выбором:

rg -n --no-heading -w '<SYMBOL>' | \
  fzf --delimiter : --nth=3.. \
      --preview 'bat --style=numbers --color=always {1}:{2}'

Список TODO рядом с местами использования:

rg -n 'TODO|FIXME' | rg -n -w '<SYMBOL>' -n

Быстрые шорткаты (обёртки)

def()  { rg -n --pcre2 -w "^(\\s*(fn|def|class|struct|type)\\s+)?$1\\b" $(git ls-files); }
refs() { rg -n -w "$1" $(git ls-files); }
calls(){ rg -n --pcre2 "\\b$1\\s*\\(" $(git ls-files); }
jump() { rg -n -w "$1" $(git ls-files) | fzf | awk -F: '{print "+"$2" "$1}' | xargs ${EDITOR:-vim}; }

Опционально: ctags как ускоритель стартового “jump-to-def”, но без магии:

ctags -R --fields=+n
grep -m1 -P "^\Q<SYMBOL>\E\t" tags | cut -f2,3 | awk -F'\t' '{print "+"$2" "$1}' | xargs ${EDITOR:-vim}

Моно- и мегарепозитории

— Фильтруйте область поиска: git grep -n -w '<SYMBOL>' -- :^vendor :^node_modules. — Делите по модулям: fd . src/moduleA | xargs rg -n -w '<SYMBOL>'. — Кэшируйте списки файлов: git ls-files > .files && rg -n -w '<SYMBOL>' -f .files.

В CI и код-ревью

— Проверка утечек/рефакторов:

rg -n -w '<OLD_NAME>' && echo "Rename незавершён" && exit 1

• Навигация в артефактах билдов: распаковали, затем всё те же команды.

Анти-паттерны LSP-навигации

• “Жду индекса” — потери времени.
• “Сервер упал” — потеря контекста.
• “Переход не нашёлся” — ложный сигнал, символ существует.
• “Работает только в IDE X” — лок-ин, плохая переносимость.

Клятва grep

• Не доверяю демонам. Доверяю тексту.
• Любая навигация должна быть воспроизводима одной строкой.
• Каждый переход должен быть объясним простым регулярным выражением.
• Скорость важнее украшений. Точность важнее подсказок. Свобода важнее интеграций.

Когда LSP уместен

Автодополнение, сложные безопасные рефакторы, подсказки типов.

Быстрый старт набора инструментов

alias GG="git grep -n --heading --break"
alias RR="rg -n --hidden --follow -S -g '!.git' -g '!node_modules' -g '!dist'"
export RIPGREP_CONFIG_PATH=~/.ripgreprc
# ~/.ripgreprc: --hidden
#                 --follow
#                 --colors line:style:nobold

Заключение

Откройте глаза: переход по коду — это поиск по тексту. grep не обещает магии. Он показывает правду.

Имхо каждый должен иметь возможность настроить свою среду разработки так, как ему удобно, без всяких жестко фиксированных pylsp. Общие проверки нужно выносить в CI, с возможностью повторить CI-пайплайн локально вручную или через pre-commit, для тех, кому хочется.

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

Хороший вброс, мне нравится. Можно сделать отдельной темой.

Конечно, есть grep

Это не так удобно.

Для этого можно посмотреть в сторону каких-нибудь devcontainers.

Для этого можно посмотреть в сторону каких-нибудь devcontainers.

Настроить между neovim, vim и vscode оказалось чудовищно сложно. То есть можно попердолиться, но это того не стоит, если можно написать один конфиг для pyright и сделать venv.

Хороший наброс, но это сродни парсингу HTML регулярками. Хотя для динамических скриптовых языков, пожалуй, в самый раз — там все равно ничего не понятно, пока до выполнения дело не дойдет. А для компилируемых LSP все же получше будет.

Хороший наброс, но это сродни парсингу HTML регулярками. Хотя для динамических скриптовых языков, пожалуй, в самый раз — там все равно ничего не понятно, пока до выполнения дело не дойдет. А для компилируемых LSP все же получше будет.

В целом что pyright, что pylsp по коду ходят хорошо. pyright даже типы показывает прилично.

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

Ограничивать себя одним - многое терять. Года до 2010-го, когда перешёл на IntelliJ, использовал только grep - это было пыткой. IntelliJ и, позднее, LSP, очень много добавили к комфорту работы с большими проектами.

Был очень короткий этап когда я под PyCharm сидел, как раз ради более-менее рабочего jump-to. Иногда, например когда разбираешься в новой кодовой базе, действительно без IDE с LSP - сложно. Но вообще сейчас уже часто вместо того чтобы самому что-то в коде искать - быстрее нейронку попросить сразу пофиксить что надо.