История менеджеров версий.

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

Менеджеры версий помогают поддерживать несколько копий программного обеспечения параллельно друг с другом. Мы много пишем на Ruby и Node, поэтому используем Менеджер версий Ruby (RVM) и Менеджер версий узлов (NVM), но для большинства языков программирования есть много других.

У нас есть что-то вроде любви-ненависти в отношениях с обоими. В основном:

  • RVM довольно сильный нападающий. Вы можете использовать его для управления несколькими гемсетами, псевдонимами версий Ruby и многим другим. Это немного избыточно для машины разработки (хотя полезно для развертывания на серверах). Вот почему вместо этого многие люди используют rbenv.
  • NVM принципиально не поддерживает автоматическое переключение версий при переходе в директорию. Вы должны установить avn или сделать индивидуальную интеграцию с оболочкой. Лично у меня также были проблемы с производительностью, и у меня всегда был ярлык в моем .zshrc, чтобы пропустить процесс загрузки nvm по умолчанию.
  • Запоминание этого нюанса и других различий между ними — накладные расходы.

Я слышал хорошие отзывы о asdf-vm, и я также хотел поэкспериментировать с заменой zsh на fish, поэтому решил сделать и то, и другое сразу.

Вот что я узнал…

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

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

Он будет поддерживать ваши существующие файлы .‹lang›-версии… в основном

asdf предлагает вам использовать его соглашение .tool-versions, но если вы установите legacy_versions в yes, он с радостью будет использовать ваши существующие файлы .ruby-version и .node-version. У вас могут возникнуть некоторые проблемы, если вы делаете очень специфичные для версии вещи, такие как 15.x для NodeJS, которые asdf не всегда поддерживает.

Автоматическое переключение версий не самое быстрое из коробки.

asdf основан на прокладке. Это означает, что когда вы вводите ruby или node, вы вызываете asdf exec, который проверяет ваши .tool-versions (или устаревшие файлы) и решает, какую версию запускать каждый раз, когда вы вводите команду. Это медленнее, и если вы печатаете много, это может сложить. Кроме того, если вы используете приглашение командной строки, такое как starship.rs, которое отображает ваши версии в командной строке, это замедляет каждую команду. Ой.

Если вас это беспокоит, есть решение! Объедините direnv с asdf, используя asdf-direnv. direnv — это инструмент для управления переменными среды для каждого проекта (вы даже можете использовать его как суперлегкий менеджер версий…!). После того, как вы настроите его, добавьте в свой проект файл .envrc, который просто говорит use asdf, затем запустите direnv allow, чтобы разрешить его. Вы можете .gitignore этот файл, если ваши товарищи по команде не используют asdf.

`rvm взорвать && rm -rf ~/.nvm`?

Замена на asdf-vm была простой, но не безболезненной. Не очень приятно использовать конфигурацию «устаревших версий», и первоначальные проблемы с производительностью действительно напоминали проблемы, которые у меня были с nvm. У меня также были две дополнительные проблемы во время установки:

  • asdf nodejs list all не работал из-за этой проблемы. Кажется, сейчас это исправлено, но на какое-то время это застало меня врасплох.
  • Изначально asdf ruby install x перекомпилировал openssl каждый раз, что очень болезненно. Я не знаю, была ли это только моя машина, но оказалось, что мне пришлось не только прочитать asdf-ruby README, но и просмотреть вики ruby-build, чтобы найти Предлагаемую среду сборки, которая рекомендует экспортировать дополнительную среду. переменная, чтобы указать ruby-build использовать доморощенную версию openssl. RVM может быть сильным нападающим, но по крайней мере, он автоматически определяет Homebrew для зависимостей.

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

Надеюсь, это помогло вам решить, какой инструмент использовать для управления версиями вашего языка программирования. Если вы думаете, что я что-то упустил, взвешивая эти варианты, оставьте комментарий или свяжитесь! (кроме того, чтобы сказать мне просто использовать docker, это не проще)