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

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

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

В начале мы выбрали Bash для создания GVM, потому что он закрывал все требования. Он был доступен на всех *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. Конечно, это также позволит нам пересмотреть то, как он функционирует в настоящее время. Через шесть лет мы узнали, что работает и не работает, и можем довести эти знания до ума в нашей блестящей новой версии.

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

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

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

Комментарии (14)


  1. Borz
    23.09.2018 19:17

    OFF: в голосовалке не хватает пункта "иное" — пришлось воздержаться.


    А вообще молодцы — для их проекта уже давно пора было от скриптов уйти


    1. jreznot Автор
      23.09.2018 19:21

      Немного странно только, что Go. Но ничего стабильнее наверное просто не существует, Kotlin/Scala native слишком молоды, а Rust просто сложный.


      1. SirEdvin
        23.09.2018 22:28

        Вы не поверите, для скриптов есть python) Довольно стабильный.


        1. Borz
          23.09.2018 22:30
          +1

          и возвращаемся к проблеме как с Bash :) разные версии, необходимость что-то ставить на Windows, etc


          1. kalininmr
            24.09.2018 00:09

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


            1. Borz
              24.09.2018 00:57

              везде есть 2.7

              Ах если бы это было так. Когда-то для себя выбирал на чём скриптоваться и выбрал bash


              1. kalininmr
                24.09.2018 01:48

                ну тогда и bash не совсем везде :)


              1. Sirikid
                24.09.2018 20:51

                Если уж и завязываться на шелл, то только на POSIX sh.


            1. domix32
              24.09.2018 15:14

              найдете в дефолтной windows python 2.7? А так да все чаще желаю смерти bash в пользу python


              1. kalininmr
                24.09.2018 17:11

                в bash там какой версии подефолту? :)


                1. Borz
                  24.09.2018 17:32

                  Так одна из причин ухода с bash как раз из-за того, что его в Win нет по-умолчанию.


                  1. kalininmr
                    24.09.2018 18:09

                    я сравнивал bash vs python.
                    наличие примерно одинаковое.
                    а писать на питоне всяко удобнее.


      1. mad_nazgul
        24.09.2018 06:21

        Наверное, потому что «стильно, модно, молодежно».
        А так ко второй версии изменять систему работу с модулями, добавят дженерики и работу с исключениями. Вот тогда Go можно посмотреть. :-)


      1. ggo
        24.09.2018 10:18

        Serverless… же

        deployment time становится фактором, на который обращают внимание.