Хабрахабр

[Перевод] SDKMAN — мёртв, да здравствует SDKMAN

TL;DR: SDKMAN CLI будет переписан на Golang

В более ранних версиях он был известен как GVM и использовался для управления Groovy и связанным с ним инструментарием. Шесть лет прошло с тех пор как мы выпустили первую версию SDKMAN. В этот момент GVM был переименован в SDKMAN. Вскоре стало очевидно, что он не должен ограничиваться экосистемой Groovy, и может также применяться к другим SDK на JVM. Хотя название и изменилось, основная технология осталась прежней.

Несмотря на то, что сервисы бэкенда были заменены лучшими альтернативами, CLI клиент остался прежним и стал нашим самым большим источником разочарования.
В начале мы выбрали Bash для создания GVM, потому что он закрывал все требования. Подобно тому, как GVM однажды перерос своё имя, SDKMAN перерос технологию, на которой он был построен. Это означало, что загрузка новой установки практически не требовала усилий почти на любой системе. Он был доступен на всех *nix системах, быстро работал и предоставлял нам среду исполнения без каких-либо дополнительных зависимостей или накладных расходов.

Несмотря на преимущества, которые нам дал Bash, со временем мы обнаружили множество проблем с этим выбором:

  • пользователи Windows должны прыгать через обручи, устанавливая Cygwin / Git Bash
  • наше программное обеспечение не всегда хорошо работает с альтернативными оболочками, такими как Fish shell
  • необходимо поддерживать специальные хаки для совместимости с ZSH
  • несовместимость между основными версиями Bash (и упорный отказ Apple от поставки OSX с современной версией Bash из-за глупых вопросов лицензирования)
  • проблемы с сетью из-за использования curl в качестве основного http-клиента
  • сложности с эффективным тестированием кода на Bash

Все это говорит нам, что пора бросить Bash в пользу чего-то еще, поэтому в последние месяцы я начал изучать Go как жизнеспособную альтернативу. После взвешивания шансов, плюсы реализации CLI на Go можно суммировать следующим образом:

  • статически типизированный компилируемый язык, позволяющий обнаруживать ошибки во время разработки
  • исполняется невероятно быстро
  • больше нет зависимости от зыбкой почвы Bash под ногами
  • создает изначально скомпилированные двоичные файлы для всех архитектур, устраняя неожиданные связанные с платформой побочные эффекты
  • более легкая поддержка приемочного тестирования через Godog (версия Cucumber, написанная в Go)
  • позволяет переосмыслить некоторое поведение текущей реализации SDKMAN (подробнее об этом позже)
  • позволяет улучшить сотрудничество и увеличить вклад членов сообщества
  • прост и позволяет нам просто сделать эту чертову работу (Get Shit Done)

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

Мы хотим знать, какие функции вы хотели бы видеть (или не хотели бы). Здесь мы призываем наше сообщество присоединиться и стать частью общения. Мы приглашаем вас присоединиться и принять участие, давая обратную связь на новый CLI. Для этого мы открываем новую комнату в Gitter. Как и прежде, мы хотим, чтобы эти функции составляли живую документацию. Мы все еще используем Cucumber для описания поведения в понятном для понимания языке так же, как и в случае с версией Bash, и просим всех принять участие в реализации каждой функции.

Нам нравилось разрабатывать оригинальную версию SDKMAN, но мы поняли, что в ней есть проблемы. Именно поэтому я назвал этот пост так. Мы будем рады любой помощи на пути к реализации нового CLI! Теперь у нас есть возможность сделать его более надежным и улучшить его для всех.

Именно поэтому, совсем недавно мы в CUBA Platform начали публиковать в SDKMAN свою утилиту CUBA CLI. От переводчика: SDKMAN — один из самых любимых мною пакетных менеджеров, с него начинается установка JVM, Gradle и Kotlin на новой машине. Я сделал этот перевод, поскольку рад видеть развитие SDKMAN и с нетерпением жду его новой версии.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть